SEC06-BP03 手動管理とインタラクティブアクセスを削減する - AWS Well-Architected Framework
実装のガイダンスリソース

SEC06-BP03 手動管理とインタラクティブアクセスを削減する

デプロイ、構成、保守、調査のタスクは、可能な限り自動化します。自動化を利用できない場合は、緊急対応が必要な事態や安全な (サンドボックス) 環境でのコンピューティングリソースへの手動アクセスを検討してください。

期待される成果: プログラムスクリプトや自動化ドキュメント (ランブック) に、コンピューティングリソースに対して承認されるアクションが定義されています。これらのランブックは、変更検出システムによって自動的に開始されるか、人間による判断が必要な場合は手動で開始されます。コンピューティングリソースへの直接アクセスは、自動化を利用できない緊急時にのみ可能です。手動のアクティビティはすべてログに記録され、自動化機能を継続的に改善していくため、レビュープロセスに組み込まれます。

一般的なアンチパターン:

  • SSH や RDP などのプロトコルを使用して、Amazon EC2 インスタンスにインタラクティブにアクセスする。

  • /etc/passwd や Windows ローカルユーザーなど、個々のユーザーログインを管理している。

  • インスタンスにアクセスするためのパスワードまたはプライベートキーを複数のユーザー間で共有している。

  • 手動でソフトウェアをインストールし、構成ファイルを作成または更新している。

  • 手動でソフトウェアを更新するかパッチを適用する。

  • インスタンスにログインして問題をトラブルシューティングする。

このベストプラクティスを活用するメリット: アクションの実行を自動化することで、意図しない変更や構成ミスによる運用上のリスクを軽減できます。インタラクティブアクセスに Secure Shell (SSH) や Remote Desktop Protocol (RDP) を使用しなくなれば、コンピューティングリソースへのアクセスの範囲が限定されます。これにより、不正行為に対して一般的な経路を遮断できます。コンピューティングリソースの管理タスクを自動化ドキュメントやプログラムスクリプトに定義しておくことで、承認されるアクティビティの全範囲をきめ細かく定義および監査するメカニズムを確立できます。

このベストプラクティスが確立されていない場合のリスクレベル: 中

実装のガイダンス

インスタンスへのログインは、システム管理における従来のアプローチです。サーバーのオペレーティングシステムをインストールした後、ユーザーは通常手動でログインしてシステムを設定し、必要なソフトウェアをインストールします。サーバーの存続期間中、ユーザーはログインしてソフトウェアの更新、パッチの適用、構成の変更、問題のトラブルシューティングを行うことができます。

ただし、手動アクセスは多くのリスクを伴います。サーバーは SSH や RDP サービスなどのリクエストをリスニング (待ち受け) しなければならず、それが不正アクセスに対して経路を開くことになりかねません。また、手作業による人為的ミスのリスクも高まります。その結果、ワークロードインシデント、データの破損や破壊、その他のセキュリティ問題が発生するおそれがあります。また、人為的アクセスには認証情報の共有に対する保護も必須となり、管理オーバーヘッドが増えます。 

これらのリスクを軽減するために、AWS Systems Manager などのエージェントベースのリモートアクセスソリューションを実装できます。AWS Systems Manager Agent (SSM Agent) は、暗号化されたチャネルを自ら確立するため、外部発信のリクエストを待ち受ける必要がありません。VPC エンドポイントを介してこのチャネルを確立するように SSM Agent を設定することを検討してください。

Systems Manager では、マネージドインスタンスとの対話方法をきめ細かく制御できます。実行する自動化、実行できるユーザー、実行できるタイミングを定義します。Systems Manager では、インスタンスにインタラクティブにアクセスしなくても、パッチの適用、ソフトウェアのインストール、設定の変更を行うことができます。また、Systems Manager でリモートシェルへのアクセスを確立し、セッション中に呼び出されたすべてのコマンドとその出力をログと Amazon S3 に記録することもできます。AWS CloudTrail は、Systems Manager API の呼び出しを検査のために記録します。

実装手順

  1. Amazon EC2 インスタンスに AWS Systems Manager Agent (SSM Agent) をインストールします。SSM Agent が基本の AMI 構成に組み込まれていて、自動的に起動されるかどうかを確認してください。

  2. EC2 インスタンスプロファイルに関連付けられている IAM ロールに、AmazonSSMManagedInstanceCore マネージド IAM ポリシーが紐付けられていることを確認します。

  3. インスタンスで実行されている SSH、RDP、その他のリモートアクセスサービスを無効にします。そのためには、起動テンプレートのユーザーデータセクションで設定したスクリプトを実行するか、EC2 Image Builder などのツールを使用してカスタムの AMI を構築します。

  4. EC2 インスタンスに適用されるセキュリティグループの受信 (イングレス) ルールで、ポート 22/tcp (SSH) またはポート 3389/tcp (RDP) へのアクセスが許可されていないことを確認します。AWS Config などのサービスを使用して、セキュリティグループの構成ミスに対する検出とアラートを実装します。

  5. Systems Manager で適切な自動化、ランブックを定義し、コマンドを実行します。IAM ポリシーを使用して、これらのアクションを実行できるユーザーと、アクションが許可される条件を定義します。これらの自動化を本稼働環境以外で徹底的にテストしてください。インスタンスにインタラクティブにアクセスする代わりに、必要に応じてこれらの自動化を呼び出します。

  6. AWS Systems Manager Session Manager を使用して、インスタンスへのインタラクティブアクセスを適宜確立します。セッションアクティビティのログ記録を有効にして、Amazon CloudWatch Logs または Amazon S3 に監査証跡を残します。 

リソース

関連するベストプラクティス:

関連する例:

関連ツール:

関連動画: