「サーバの管理」の版間の差分
Shitami.junichiro (トーク | 投稿記録) |
|||
(同じ利用者による、間の10版が非表示) | |||
6行目: | 6行目: | ||
セキュリティ事故を起こさないためには以下のような点に注意してサーバの管理を行う必要があります。 | セキュリティ事故を起こさないためには以下のような点に注意してサーバの管理を行う必要があります。 | ||
+ | 特に外部に公開するサーバではセキュリティアップデートは必須となります。 | ||
− | + | === セキュリティアップデートを行い脆弱性のないソフトウェアを利用する === | |
− | |||
− | |||
− | == | + | サーバで使用している OS やライブラリ、サーバソフトウェアに脆弱性があると外部から攻撃を受けてサーバに侵入されてしまいます。 |
+ | サーバに侵入されると、サーバ上のデータの漏えい、公開している情報の改ざん、他組織への攻撃や迷惑行為への踏み台としての利用、などの被害が発生し大変問題ですので、 | ||
+ | セキュリティアップデートを行い脆弱制のないソフトウェアを利用するのは必要不可欠です。 | ||
+ | |||
+ | * セキュリティアップデートの行われているOSを利用する | ||
+ | |||
+ | 各ソフトウェアについて個別にセキュリティ問題の確認やアップデートの対応を行うのは非常に作業量が多く現実的ではありません。 | ||
+ | 適切にセキュリティアップデートが行われているOSを利用してサーバを構築し、自動アップデート機能を利用してアップデートを行う運用を推奨します。 | ||
+ | |||
+ | セキュリティアップデートの対応についてもOSの種類などによって差があります。 | ||
+ | サーバ用途で使用する場合は、例えばRedHat互換OSのようにサーバ用途を目的として広く使用されており、適切にアップデートが行われている | ||
+ | (サポートのライフタイムが明示されている、各セキュリティインシデントへの対応状況が分かりやすい)ものを使用することを推奨します。 | ||
+ | |||
+ | * 既にセキュリティアップデートの対応がされなくなった古いソフトウェアは利用しない | ||
+ | |||
+ | 既にセキュリティアップデートの対応がされなくなっている古いソフトウェア(もしくは古いメジャーバージョン)については最新のものを使用していても安全ではありません。 | ||
+ | 既知のセキュリティ問題についてもアップデートされていないだけでなく、セキュリティ問題があるかどうかも適切な情報がない可能性が高いです。 | ||
+ | |||
+ | === アカウントを適切に管理する === | ||
+ | |||
+ | サーバに脆弱性がない状態でも、アカウントの管理が適切でない場合にサーバに侵入されてしまいます。 | ||
+ | アカウントの適切な管理は必要不可欠です。 | ||
+ | |||
+ | * 不要なアカウントは削除する | ||
+ | |||
+ | 常時使用されていないアカウントは管理がおろそかになりがちですので、不要なアカウントは削除してください。 | ||
+ | 特に構築時にデフォルトで作成されるアカウントや、テストとして一時的に作成したアカウントは問題を起こしがちです。 | ||
+ | |||
+ | * 適切なパスワードを設定する | ||
+ | |||
+ | パスワードは簡単に推測できない複雑なものを設定する必要があります。 | ||
+ | 十分に複雑なパスワードとしては、たとえば長さが8文字以上で、大文字・小文字・数字・記号のうち3種類以上を用いてください。 | ||
+ | パスワードが複雑でもシステムのデフォルトパスワードなど外部の人がドキュメントの閲覧等で知りえるパスワードは適切ではありません。 | ||
+ | |||
+ | == 外部に公開するサーバの管理 == | ||
+ | |||
+ | === サーバを外部に公開する前に === | ||
+ | |||
+ | 理学系研究科ではデフォルトでは外部からのアクセスはファイアウォールで遮断しています。 | ||
+ | 必要なポートについては申請に基づいて設定を行いますが、昨今のセキュリティインシデントのほとんどは外部に公開しているサーバで発生していることを考慮したうえで、 | ||
+ | 外部に公開する必要性について十分な検討を行ってください。 | ||
+ | |||
+ | * VPNの活用 | ||
+ | |||
+ | 外部からの利用が必要なサーバについても、利用者が内部の人のみである場合は、VPN を使用して外部から内部のネットワークに接続することが可能です。 | ||
+ | この場合、各サーバは外部からの攻撃を受けることはありませんのでより直接公開するより安全です。 | ||
+ | VPNの利用方法については[[VPN接続サービス]]のページを参照してください。 | ||
+ | |||
+ | * IPアドレス限定での公開 | ||
+ | |||
+ | 外部からの利用が必要なサーバで、利用者も外部の人である場合でも、利用者が不特定多数でない場合については、その利用者が利用するネットワークのIPアドレスを指定して公開することが可能です。 | ||
+ | この場合、攻撃者が対象の組織にいる場合にしか攻撃を受けませんので、全体に公開するより安全です。 | ||
+ | |||
+ | * ログインサーバの設置など | ||
+ | |||
+ | 不特定多数の利用者が外部から利用が必要な場合でも、各サーバを直接公開する必要があるかを検討してください。 | ||
+ | 個別のシステムなどを構築していて定期的なアップデートが困難なサーバは外部への公開には適切ではありません。 | ||
+ | 組織ごとに代表するログインサーバを設置し、そこを経由してログインするなどの利用方法を検討してください。 | ||
=== 管理情報の登録 === | === 管理情報の登録 === | ||
− | + | 昨今では外部に公開したサーバに起因するセキュリティ問題が増加しておりますので、サーバを外部に公開する場合には以下の情報を登録していただいております。 | |
また、年に一度確認をさせていただき、管理が行われなくなってしまったサーバについては公開を停止させていただいております。 | また、年に一度確認をさせていただき、管理が行われなくなってしまったサーバについては公開を停止させていただいております。 | ||
21行目: | 77行目: | ||
2. IPアドレス | 2. IPアドレス | ||
3. FQDN | 3. FQDN | ||
− | 4. | + | 4. 責任者氏名 |
− | 5. | + | 5. 責任者メールアドレス |
6. 担当者氏名 | 6. 担当者氏名 | ||
7. 担当者メールアドレス | 7. 担当者メールアドレス | ||
8. 用途 | 8. 用途 | ||
− | 9. 備考 | + | 9. 最新のセキュリティアップデートを適用済みであるかどうか |
+ | 10. syslog転送先(sshサーバの場合) | ||
+ | 11. 備考 | ||
=== Webサーバの管理 === | === Webサーバの管理 === | ||
35行目: | 93行目: | ||
* セキュリティアップデートの提供されている OS を利用すし、常に最新にアップデートを行う | * セキュリティアップデートの提供されている OS を利用すし、常に最新にアップデートを行う | ||
− | * CMS | + | * WordPress などの CMS を利用する場合には常に最新版を利用する |
* PHPなどのプログラムを利用する場合には、セキュリティ問題などに対応できるような体制にする | * PHPなどのプログラムを利用する場合には、セキュリティ問題などに対応できるような体制にする | ||
+ | * Wiki や掲示板といった編集や書き込みが可能なコンテンツは不適切な書き込みが行われないように認証を行う | ||
+ | |||
+ | ウェブサーバのセキュリティアップデートの管理を各自で行うのが困難な場合は[[Webホスティングサービス]]の利用を検討してください。 | ||
+ | |||
+ | === ssh サーバの管理 === | ||
+ | |||
+ | sshサーバではサーバに直接ログインが可能なため、各種ライブラリを含むOSのアップデートが必要不可欠です。 | ||
+ | 発注してシステムを構築する場合には、その後の保守運用がおろそかになったり、またはアップデート方法が不明なこともあるかと思います。 | ||
+ | 本当にそのサーバを直接外部に公開するのが適切かどうか十分に検討してください。 | ||
+ | |||
+ | * syslog の転送 | ||
+ | |||
+ | 外部に公開しているsshサーバでは、万が一侵入などの被害を受けた場合に、 | ||
+ | そこを踏み台としたさらなる被害など大きな影響を与える一方で、ログの改ざんなどで調査が難しくなるという問題があります。 | ||
+ | 外部に公開しているsshサーバではsyslogの別サーバへの転送を必須とし、上記の確認事項の他にsyslogの転送先を確認させていただきます。 | ||
+ | syslogの転送先としては研究科で用意しているsyslogサーバも利用可能ですので、詳細についてはお問い合わせください。 | ||
+ | * 鍵認証のみでのログイン | ||
− | == | + | sshサーバでは特にアカウントの適切な管理が必要です。 |
+ | sshサーバを外部に公開する場合には鍵認証のみでのログインを推奨します。 | ||
+ | どうしても鍵認証のみでの管理が難しい場合には、アカウントの管理を徹底してください。 | ||
+ | |||
+ | == ssh サーバの鍵認証での利用について == | ||
− | |||
パスワードでログイン可能なsshサーバを適切に管理するには、サーバに存在する全てのアカウントが適切なパスワードを付けていることを確認する必要があります。 | パスワードでログイン可能なsshサーバを適切に管理するには、サーバに存在する全てのアカウントが適切なパスワードを付けていることを確認する必要があります。 | ||
適切な状態を維持するのは大変で、一時的に作ったアカウントの消し忘れなどからsshで侵入される事例が発生しています。 | 適切な状態を維持するのは大変で、一時的に作ったアカウントの消し忘れなどからsshで侵入される事例が発生しています。 | ||
鍵認証でしかログインできない設定ではこういった問題は発生しません。 | 鍵認証でしかログインできない設定ではこういった問題は発生しません。 | ||
− | |||
− | |||
− | |||
− | |||
=== ユーザの設定 === | === ユーザの設定 === | ||
* ssh-keygen コマンドを実行します。 | * ssh-keygen コマンドを実行します。 | ||
− | ** 質問にエンターを入力します(ファイルの場所はデフォルト、パスフレーズなし) | + | ** デフォルトではrsaの鍵となりますが最近ではセキュリティ的に問題があると考えられているためed25519を指定します |
− | * .ssh/ | + | ssh-keygen -t ed25519 |
+ | * 質問にエンターを入力します(ファイルの場所はデフォルト、パスフレーズなし) | ||
+ | * .ssh/id_ed25519 が秘密鍵、.ssh/id_ed25519.pub が公開鍵です(ファイル名は指定したタイプによって異なります) | ||
* サーバの .ssh/authorized_keys に公開鍵を追加します | * サーバの .ssh/authorized_keys に公開鍵を追加します | ||
− | ** サーバに | + | ** サーバに id_ed25519.pub をコピーしてから |
− | cat | + | cat id_ed25519.pub >> .ssh/authorized_keys |
* .ssh ディレクトリに g や o の書き込み権限がたってないことを確認します | * .ssh ディレクトリに g や o の書き込み権限がたってないことを確認します | ||
2024年5月9日 (木) 10:30時点における最新版
目次
1 全般的なサーバの管理
セキュリティ事故を起こさないためには以下のような点に注意してサーバの管理を行う必要があります。 特に外部に公開するサーバではセキュリティアップデートは必須となります。
1.1 セキュリティアップデートを行い脆弱性のないソフトウェアを利用する
サーバで使用している OS やライブラリ、サーバソフトウェアに脆弱性があると外部から攻撃を受けてサーバに侵入されてしまいます。 サーバに侵入されると、サーバ上のデータの漏えい、公開している情報の改ざん、他組織への攻撃や迷惑行為への踏み台としての利用、などの被害が発生し大変問題ですので、 セキュリティアップデートを行い脆弱制のないソフトウェアを利用するのは必要不可欠です。
- セキュリティアップデートの行われているOSを利用する
各ソフトウェアについて個別にセキュリティ問題の確認やアップデートの対応を行うのは非常に作業量が多く現実的ではありません。 適切にセキュリティアップデートが行われているOSを利用してサーバを構築し、自動アップデート機能を利用してアップデートを行う運用を推奨します。
セキュリティアップデートの対応についてもOSの種類などによって差があります。 サーバ用途で使用する場合は、例えばRedHat互換OSのようにサーバ用途を目的として広く使用されており、適切にアップデートが行われている (サポートのライフタイムが明示されている、各セキュリティインシデントへの対応状況が分かりやすい)ものを使用することを推奨します。
- 既にセキュリティアップデートの対応がされなくなった古いソフトウェアは利用しない
既にセキュリティアップデートの対応がされなくなっている古いソフトウェア(もしくは古いメジャーバージョン)については最新のものを使用していても安全ではありません。 既知のセキュリティ問題についてもアップデートされていないだけでなく、セキュリティ問題があるかどうかも適切な情報がない可能性が高いです。
1.2 アカウントを適切に管理する
サーバに脆弱性がない状態でも、アカウントの管理が適切でない場合にサーバに侵入されてしまいます。 アカウントの適切な管理は必要不可欠です。
- 不要なアカウントは削除する
常時使用されていないアカウントは管理がおろそかになりがちですので、不要なアカウントは削除してください。 特に構築時にデフォルトで作成されるアカウントや、テストとして一時的に作成したアカウントは問題を起こしがちです。
- 適切なパスワードを設定する
パスワードは簡単に推測できない複雑なものを設定する必要があります。 十分に複雑なパスワードとしては、たとえば長さが8文字以上で、大文字・小文字・数字・記号のうち3種類以上を用いてください。 パスワードが複雑でもシステムのデフォルトパスワードなど外部の人がドキュメントの閲覧等で知りえるパスワードは適切ではありません。
2 外部に公開するサーバの管理
2.1 サーバを外部に公開する前に
理学系研究科ではデフォルトでは外部からのアクセスはファイアウォールで遮断しています。 必要なポートについては申請に基づいて設定を行いますが、昨今のセキュリティインシデントのほとんどは外部に公開しているサーバで発生していることを考慮したうえで、 外部に公開する必要性について十分な検討を行ってください。
- VPNの活用
外部からの利用が必要なサーバについても、利用者が内部の人のみである場合は、VPN を使用して外部から内部のネットワークに接続することが可能です。 この場合、各サーバは外部からの攻撃を受けることはありませんのでより直接公開するより安全です。 VPNの利用方法についてはVPN接続サービスのページを参照してください。
- IPアドレス限定での公開
外部からの利用が必要なサーバで、利用者も外部の人である場合でも、利用者が不特定多数でない場合については、その利用者が利用するネットワークのIPアドレスを指定して公開することが可能です。 この場合、攻撃者が対象の組織にいる場合にしか攻撃を受けませんので、全体に公開するより安全です。
- ログインサーバの設置など
不特定多数の利用者が外部から利用が必要な場合でも、各サーバを直接公開する必要があるかを検討してください。 個別のシステムなどを構築していて定期的なアップデートが困難なサーバは外部への公開には適切ではありません。 組織ごとに代表するログインサーバを設置し、そこを経由してログインするなどの利用方法を検討してください。
2.2 管理情報の登録
昨今では外部に公開したサーバに起因するセキュリティ問題が増加しておりますので、サーバを外部に公開する場合には以下の情報を登録していただいております。 また、年に一度確認をさせていただき、管理が行われなくなってしまったサーバについては公開を停止させていただいております。
1. 専攻施設 2. IPアドレス 3. FQDN 4. 責任者氏名 5. 責任者メールアドレス 6. 担当者氏名 7. 担当者メールアドレス 8. 用途 9. 最新のセキュリティアップデートを適用済みであるかどうか 10. syslog転送先(sshサーバの場合) 11. 備考
2.3 Webサーバの管理
Webサーバの管理では、最初の構築だけではなく継続的な管理が重要となります。 発注などでサイトを構築する場合には、サーバの管理がおろそかになりがちですが、サーバの管理体制を十分考慮して公開を行ってください。 特に、定期的なソフトウェアのアップデートは重要で、コンテンツの表示や動作の互換性がアップデートの妨げにならないように、コンテンツの修正などが定常的に行える体制を整える必要があります。
- セキュリティアップデートの提供されている OS を利用すし、常に最新にアップデートを行う
- WordPress などの CMS を利用する場合には常に最新版を利用する
- PHPなどのプログラムを利用する場合には、セキュリティ問題などに対応できるような体制にする
- Wiki や掲示板といった編集や書き込みが可能なコンテンツは不適切な書き込みが行われないように認証を行う
ウェブサーバのセキュリティアップデートの管理を各自で行うのが困難な場合はWebホスティングサービスの利用を検討してください。
2.4 ssh サーバの管理
sshサーバではサーバに直接ログインが可能なため、各種ライブラリを含むOSのアップデートが必要不可欠です。 発注してシステムを構築する場合には、その後の保守運用がおろそかになったり、またはアップデート方法が不明なこともあるかと思います。 本当にそのサーバを直接外部に公開するのが適切かどうか十分に検討してください。
- syslog の転送
外部に公開しているsshサーバでは、万が一侵入などの被害を受けた場合に、 そこを踏み台としたさらなる被害など大きな影響を与える一方で、ログの改ざんなどで調査が難しくなるという問題があります。 外部に公開しているsshサーバではsyslogの別サーバへの転送を必須とし、上記の確認事項の他にsyslogの転送先を確認させていただきます。 syslogの転送先としては研究科で用意しているsyslogサーバも利用可能ですので、詳細についてはお問い合わせください。
- 鍵認証のみでのログイン
sshサーバでは特にアカウントの適切な管理が必要です。 sshサーバを外部に公開する場合には鍵認証のみでのログインを推奨します。 どうしても鍵認証のみでの管理が難しい場合には、アカウントの管理を徹底してください。
3 ssh サーバの鍵認証での利用について
パスワードでログイン可能なsshサーバを適切に管理するには、サーバに存在する全てのアカウントが適切なパスワードを付けていることを確認する必要があります。 適切な状態を維持するのは大変で、一時的に作ったアカウントの消し忘れなどからsshで侵入される事例が発生しています。 鍵認証でしかログインできない設定ではこういった問題は発生しません。
3.1 ユーザの設定
- ssh-keygen コマンドを実行します。
- デフォルトではrsaの鍵となりますが最近ではセキュリティ的に問題があると考えられているためed25519を指定します
ssh-keygen -t ed25519
- 質問にエンターを入力します(ファイルの場所はデフォルト、パスフレーズなし)
- .ssh/id_ed25519 が秘密鍵、.ssh/id_ed25519.pub が公開鍵です(ファイル名は指定したタイプによって異なります)
- サーバの .ssh/authorized_keys に公開鍵を追加します
- サーバに id_ed25519.pub をコピーしてから
cat id_ed25519.pub >> .ssh/authorized_keys
- .ssh ディレクトリに g や o の書き込み権限がたってないことを確認します
3.2 サーバの設定
- /etc/ssh/sshd_config を編集してパスワード認証を禁止します
PasswordAuthentication no
3.3 運用に関する注意点
パスワード認証によるログインを禁止した場合、新たに追加したユーザについては、 管理者がユーザの公開鍵をメールで送ってもらうなどして設定する必要があります。