Amazon Web Services ブログ

AWS アカウントのセキュリティを改善するための 10 個の項目

クラウド・セキュリティを向上させたいと考えているなら、AWS のチーフ・インフォメーション・セキュリティ・オフィサー (CISO) であるステファン・シュミットが AWS re:Invent 2019で発表したクラウド・セキュリティのための上位 10 個の項目 を参照してみてはいかがでしょうか？

下記が項目のサマリーです。皆様の理解のために、順番に説明していきます。

1) アカウント情報を正しく保つ

AWS が AWS アカウントについて連絡が必要な場合、AWS マネジメントコンソールで設定された連絡先の情報を利用します。これは、アカウントを作成する時に指定した E メールアドレス、代替の連絡先の中で指定されている E メールアドレスになります。全ての E メールアドレスは個人に依存しないようにエイリアスのアドレスにするべきです。また、定期的に指定している E メールアドレスが有効で、E メールが届いた時に返信可能かどうかを確認するプロセスが必要です。特に、 abuse@amazon.com から受信する可能性のあるセキュリティに関する通知に返信出来るかどうかが重要です。あなた自身が不在の時に、他の誰かがメール受信を出来るように代替の連絡先指定のマニュアルページで確認してみてください。

2) 多要素認証 (MFA) を利用する

MFA は不正なアクセスからアカウントを保護するためのベストな方法の１つです。MFA をルートユーザおよび AWS Identity and Access Management (IAM) ユーザに対して設定してください。AWS へのアクセス制御に AWS Single Sign-On (SSO) を使っていたり、企業内の ID ストアとフェデレーションを指定している場合には、MFA を Identity Provider (IdP) 側で設定することで、組織にある既存の MFA の仕組みのメリットを享受出来ます。実際に設定する際には AWS での多要素認証 (MFA) の使用を参照してください。

3) シークレットをハードコードしない

AWS 上でアプリケーションを構築する際に、AWS サービスを呼び出すために一時的で、短時間有効な認証情報を利用するために AWS IAM ロールを使うことが出来ます。しかし、アプリケーションによっては、データベースのパスワードやその他の API キーのように長時間有効な認証情報を必要とするものがあります。このようなケースでは、決して認証情報をハードコードしたり、ソースコードの中に埋め込んだりしないでください。

アプリケーションが使うシークレット情報を管理するために AWS Secrets Manager が利用可能です。Secrets Manager はデータベースの認証情報、APIキー、その他のシークレットのライフサイクル全般において、ローテーション、管理、取り出しを提供します。Secrets Manager API をアプリケーションから利用することで、平文でセンシティブな情報をハードコードすることなく、アプリケーションからシークレットを取り出すことが可能です。

また、ドキュメント Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与するを参照して学習することもおすすめです。最良の結果を出すために How to securely provide database credentials to Lambda functions by using AWS Secrets Manager を参照して学習することもおすすめです。

4) セキュリティグループに制限をかける

セキュリティグループは AWS 上にプロビジョニングされたリソースに対するネットワークアクセス制御の重要な方法です。セキュリティ観点の基本的なアプローチとしては、最低限必要なポートのみが必要なネットワークアドレス範囲に対してのみ開いていることを確認することです。AWS Config もしくは AWS Firewall Manager を使用してプログラム的に Virtual Private Cloud (VPC) セキュリティグループの構成が意図したとおりになっているか確認することが可能です。ネットワーク到達性ルールパッケージは、Virtual Private Network (VPC) の構成を分析して、Amazon EC2 インスタンスがインターネットや、Virtual Private Gateway、AWS Direct Connect などの外部のネットワークからアクセス可能かどうか判定することが可能です。また、AWS Firewall Manager を使用することで、自動的に AWS WAF のルールをインターネットに接続可能な AWS アカウント内のリソースに適用することが可能です。VPC セキュリティグループ内の検知と対応についてはこちらをご覧ください。

5) 明確なデータポリシーを持つ

全てのデータの価値が同じということはありません、すなわちデータの分類がセキュリティには非常に重要です。厳密なセキュリティ管理と、フレキシブルなアジャイル環境の間の複雑なトレードオフを調整することが重要です。厳密なセキュリティ管理は冗長なアクセス制御手順を必要とし、データセキュリティに対して強固な保証を提供します。ただし、このようなセキュリティ管理は、開発者がデータストアにアクセスするためのセルフサービスアクセスを必要とする、アジャイルでペースの速い開発環境とはうまく馴染みません。幅広いアクセス要件を満たすように、データ分類に対するアプローチを設計する必要があります。

データの分類は公開、プライベートのどちらのように二者択一である必要はありません。データには多様な機密レベルがあり、異なるレベルの機微性、機密性レベルに該当するデータが存在することがあります。予防的なコントロールと検知のコントロールを適切に組合わせてデータ・セキュリティ・コントロールを設計し、データの機密性を適切な状態に維持します。下記の例では、公開とプライベートに分類されるデータについて扱います。もし、現状のポリシーでデータの分類をしていない場合には、公開とプライベートという観点で整理をするのが良いスタート点となるでしょう。

分類された、もしくは分類しようとしているデータを保護するためには以下の観点が必要になります。

  1. 公開用ではない Amazon Simple Storage Service (Amazon S3) のバケットをお使いの場合、全てのデータを分離された公開アクセス用の AWS アカウントに移動します。この公開アクセス用のバケットにデータを移動するだけのポリシーを設定します（人間用のものではなく、システムに対してです）。この対策により、他の AWS アカウントにおいて公開 Amazon S3 バケットが作られることを防止出来ます。
  2. Amazon S3 ブロックパブリックアクセス を全てのアカウントで設定して Amazon S3 からデータが共有されることを禁止します。
  3. ２つの異なる IAM ロールを KMS による暗号化用と復号用に設定します。この設定によりデータの作成（暗号化）とデータのレビュー（復号）を分離することが出来ます。また、失敗した復号の試みを復号用のロールについて分析することで脅威検知が可能になります。

6) CloudTrail ログの集約化

ロギングとモニタリングは頑強なセキュリティ計画の重要な部分です。予期せぬ環境の変化を調査したり、セキュリティを改善するための継続的な分析は、データにアクセスできてこそ実現可能になります。AWS はログを書き出して保存することをおすすめしています、特に AWS CloudTrail を AWS アカウントの S3 バケットにロギング（ログアーカイブ）することです。この S3 バケットの権限設定により削除を無効化するべきですし、保管時の暗号化も設定するべきです。ログが集約化されれば、SIEM ソリューションや AWS サービスを利用してログを分析することが出来ます。詳細については このブログを参照してください。CloudTrail ログが集約化されたら、 ログアーカイブ専用のアカウントを使って CloudWatch Logs や AWS ロードバランサーからのログを集約化することも出来ます。

7) IAM ロールを確認する

AWS 環境において継続的に構築を続けていると、後から確認したときに不要と気づく IAM ロールを複数作ってしまっているケースがあります。AWS IAM Access Analyzer を使用してご自身の AWS アカウントの外部に共有されている AWS リソース を見つけ出すことが可能です。SecurityHub やオープンソースの Prowler などを利用して定期的に AWS IAM ロールと権限を確認することで、皆さんの組織のガバナンス、リスク、コンプライアンス（GRC）ポリシーに適合しているか可視化することが可能になります。もし、ここに書かれていることを既に実行済みで複数のロールをお使いの場合は、ここに書かれている方法で、使用されていない IAM ロールを見つけて削除することが可能です。

8) Findings / 結果に対してアクションをとる（GuardDutyのみではありません）

AWS Security Hub, Amazon GuardDuty, AWS Identity and Access Management Access Analyzer はAWS アカウント上の対応可能な Findings / 結果を提供するマネージド AWS サービスです。これらのサービスは簡単に有効化でき、お使いの複数のアカウントの情報を統合することが可能です。有効化するのは最初のステップにすぎません。サービスが生成した Findings / 結果に対して対応することが必要です。どうアクションするかは、皆さんの企業のインシデントレスポンスポリシーによって決まります。検出される Findings / 結果それぞれに対してどのようなアクションを取るべきか確認しておくことが必要です。

9) キーをローテーションする

Security Hub が提供する機能の１つが、AWS アカウントのコンプライアンス状況を CIS ベンチマークを使用して可視化することです。例えば、作成されてから 90 日以上経過したアクセスキーを持つ IAM ユーザーを見つけて、定期的にローテーションすることが出来ます。より詳細なガイダンスとして、AWS アクセスキーを管理するためのベストプラクティスをご参照ください。ユーザーがフェデレーション経由で AWS にアクセスしている場合は、 ユーザーにアクセスキーを発行して与える必要がなくなります。ユーザーは IdP で認証されて、AWS アカウント上の IAM ロールを引き受けます。この結果、長期間有効な認証情報が必要なければ、ユーザーは IAM ロールに紐付いた短期間のみ有効な認証情報を利用することが出来ます。

10) 開発サイクルに参加する

ここまでのガイダンスは、実装可能な技術的な構成方法にフォーカスしたものでした。最後のアドバイスである、「開発サイクルに参加する」は人に関するもので、組織のセキュリティ文化を向上することとも言いかえられます。組織の中で全ての部門のスタッフの役割は、ビジネスソリューションを安全に立ち上げることです。スタッフがセキュリティにフォーカスするようになると、構築しようとしている全てのものに関するセキュリティのバー、レベルを向上する必要があることを理解している他の部門のスタッフにガイドしたり、教育したり出来るようになります。セキュリティは全てのスタッフの仕事です。セキュリティという肩書がついているスタッフだけの仕事ではありません。

全ての組織におけるセキュリティ専門家が出来ることは、プロセスをシフトすることで簡単で、かつ最も望ましいアクションを最も安全なものにすることです。例えば、それぞれのチームが独自の ID フェデレーションやログソリューションを実装するべきではありません。私達は協業することでより強くなりますし、この考え方はクラウドにもそのまま当てはまります。ゴールはセキュリティをよりアプローチしやすくすることであり、同僚は、サポートが得られるということを知ることでセキュリティチームと会話しようとするでしょう。この文化の醸成に関する詳細は、こちらをご覧ください。

クラウドをもっと安全に使っていくために、もう一度この上位 10 個の項目について再確認してください。そして、実際にお使いの AWS アカウントの確認もしてみてください。 安全にソリューションを構築しましょう！

翻訳はSA 高橋が実施しました。
原文はこちらです。