AWSセキュリティのベストプラクティスとは？7つの領域と実践方法を解説

1. AWSセキュリティのベストプラクティスとは

AWSセキュリティのベストプラクティスとは、AWS上のデータやシステム、IT資産を保護するための推奨事項です。

AWSでは、ワークロードを適切に設計・運用するためのベストプラクティスや考え方を「AWS Well-Architected Framework」としてまとめています。AWS Well-Architected Frameworkを構成する柱の一つが「セキュリティの柱」であり、AWS環境のセキュリティを確保するための設計原則やベストプラクティスが示されています。

1-1. AWSの責任共有モデル

AWSの責任共有モデルとは、情報セキュリティに関する責任をAWSと利用者で分担する考え方です。

オンプレミス環境とAWSでは、情報セキュリティ対策の責任範囲が異なります。オンプレミスの運用経験だけを前提にAWSを設定すると、利用者が担うべき対策を見落とし、意図しない設定不備が残るおそれがあります。従来の環境との違いも踏まえ、責任共有モデルに沿って自社が管理する範囲を整理しましょう。

また、利用者が管理する範囲はAWSサービスによって異なります。AWSが運用を担う範囲の広いマネージドサービスでは、利用者の管理負担が減る一方、データやアクセス権限などは引き続き利用者による管理が必要です。利用するサービスごとに、AWSと自社それぞれの責任範囲を確認しましょう。

1-2. AWS Well-Architected Frameworkにおける7つの設計原則

AWS Well-Architected Frameworkを構成する柱の一つが「セキュリティの柱」です。セキュリティの柱では、安全なワークロードを設計・運用するための7つの設計原則が示されています。

参照：セキュリティ基盤 - セキュリティの柱

これらは、特定のAWSサービスを導入するだけで実現できるものではありません。人、手順、技術を組み合わせ、継続的に実践することが重要です。

2. AWSセキュリティのベストプラクティスを構成する7つの領域

前述した7つの設計原則は、安全なワークロードを設計・運用するうえで共通して意識したい基本的な考え方です。また、AWS Well-Architected Frameworkのセキュリティの柱では、セキュリティに関するベストプラクティスが以下の7つの領域に分けて整理されています。

• セキュリティ基盤
• Identity and Access Management（IDとアクセス管理）
• 検出
• インフラストラクチャの保護
• データ保護
• インシデントへの対応
• アプリケーションのセキュリティ

ここからは、それぞれの領域で実践したいベストプラクティスを具体的に解説します。

参照：セキュリティ基盤 - セキュリティの柱

2-1. セキュリティ基盤を整備する

セキュリティ基盤とは、個別の設定やツールを導入する前提となる、組織全体の方針や管理体制のことです。まず、経営層、情報セキュリティ担当者、開発・運用担当者などの役割と責任を明確にします。守るべき情報資産、達成したい目標、許容できるリスクも整理しましょう。

複数のシステムを運用する場合は、本番環境と開発環境、担当部門などに応じてAWSアカウントを分ける方法があります。アカウントを分離することで、一つの環境で問題が発生した際の影響範囲を限定しやすくなります。AWS Organizationsを利用すると、複数のAWSアカウントをまとめて管理し、組織単位で権限の範囲を制御することが可能です。

さらに、新しいAWSサービスやセキュリティ機能を定期的に評価し、自社の課題や要件に応じて導入を検討します。

2-2. IDとアクセス権限を管理する

「誰が、どのリソースに、何をできるか」を適切に制御します。従業員などのIDは可能な限り一元管理し、ログイン時にはパスワードに加えて別の要素で本人確認を行う多要素認証（MFA）を設定しましょう。

AWSアカウントのルートユーザーは強い権限を持つため、日常的な作業には使用しません。人やシステムがAWSへアクセスする際は、業務に必要な最小限の権限を付与し、可能な場合は有効期限のある一時的な認証情報を利用します。IAMユーザーのアクセスキーなどの長期的な認証情報を使用する場合は、用途と管理者を明確にし、適切に管理しましょう。

業務変更や人事異動のあとに不要なIDや権限が残ることもあります。未使用の認証情報や過剰な権限を定期的に確認し、不要になったものは削除しましょう。

2-3. ログと検出結果を継続的に監視する

不正な操作や設定変更へ対応するには、発生した事象を追跡できる状態を整える必要があります。必要なログを取得し、標準化した場所へ集約しましょう。

ログの記録や情報セキュリティ上の問題の検出には、主に以下のAWSサービスを活用できます。

これらのサービスは、有効化するだけでは十分ではありません。検出結果を確認する担当者と、重要度に応じた対応期限を決めましょう。通知から調査、修復までの流れを整備し、必要に応じて対応を自動化することも大切です。

2-4. インフラストラクチャを多層的に保護する

AWS環境を保護する際は、一つの対策に依存せず、複数の層に対策を設けることが重要です。アカウントやネットワークだけでなく、サーバー上のOSやアプリケーションも保護する対象となります。一部の層を突破された場合でも、別の層で攻撃を防いだり、影響を抑えたりできる構成をめざします。

AWS上に構築する仮想ネットワークであるVPCやサブネットを用途に応じて分け、通信を制御するセキュリティグループでリソースへの通信を必要最小限に制限しましょう。また、公開するWebアプリケーションへの攻撃対策として、構成に応じてAWS WAFを利用し、不正なWebリクエストを検知・遮断する方法もあります。

Amazon EC2（仮想サーバー）など利用者がOSを管理する環境では、不要な機能を無効化し、OSやミドルウェアへセキュリティパッチを適用します。対象、頻度、担当者を決め、更新が滞らない運用を整えましょう。

2-5. データを分類して保護する

すべてのデータを同じ方法で扱うのではなく、機密性や重要度に応じて分類し、適切な保護方法を適用します。個人情報や取引情報など、漏えいや改ざんが事業へ大きな影響を与えるデータを特定し、保存場所、利用者、保存期間などを適切に管理しましょう。

Amazon S3やAmazon EBSなどのストレージサービス、データベースなどに保存するデータは、要件に応じて暗号化します。通信経路上のデータはTLSを利用して暗号化し、第三者による盗聴や改ざんのリスクを抑えます。

暗号化に用いる鍵は、AWS Key Management Service（AWS KMS）などを活用して管理し、アクセスできる利用者やサービスを必要最小限に制限しましょう。また、データの誤操作や消失に備えることも大切です。データへの直接アクセスや手作業を減らすとともに、定期的にバックアップを取得し、必要なときに復元できることを確認しましょう。

2-6. セキュリティインシデントに備える

予防や監視の対策を行っていても、セキュリティインシデントの可能性を完全になくすことはできません。発生時に迷わず行動できるよう、次のような対応の流れを事前に定めます。

1. 検知した事象の概要を確認し、担当者や関係者へ報告する
2. 影響を受けたアカウント、システム、データの範囲を特定する
3. 不正な通信を遮断したり、漏えいした認証情報を無効化したりして、被害の拡大を防ぐ
4. ログなどを分析し、原因や侵入経路を調査する
5. システムを安全な状態へ復旧し、再発防止策を反映する

あわせて、緊急時の連絡先と判断権限を定めます。調査に必要なツールやアクセス権限を準備し、ログを保全できる状態も整えておきましょう。

また、インシデント対応を想定した「ゲームデー」と呼ばれる実践訓練を定期的に行い、手順どおり対応できるかを確認します。対応後は、得られた知見を手順やシステム構成へ反映することも大切です。

2-7. 開発ライフサイクル全体でアプリケーションを保護する

アプリケーションのセキュリティ対策は、リリース直前だけでなく、設計段階から運用開始後まで継続して取り組みます。設計時には、想定される脅威と対策を洗い出す脅威モデリングを行いましょう。開発時には、コードレビューや依存関係の確認を実施します。

ビルド、テスト、デプロイを継続的に行うCI/CDパイプラインには、コードや設定のセキュリティテストを組み込みます。テストを担当者が容易に回避できないようにし、パイプライン自体のアクセス権限や認証情報も定期的に見直してください。

Amazon Inspector（脆弱性管理サービス）を活用すると、Amazon EC2インスタンスやAmazon ECRに保存されたコンテナイメージ、AWS Lambda関数などの脆弱性を継続的に検出できます。検出後の優先順位付けや修正まで含めて運用を定め、同じ問題が繰り返されないよう開発プロセスを改善しましょう。

ここまで紹介したように、AWSセキュリティのベストプラクティスは、アクセス権限やログ、ネットワーク、データ保護など幅広い領域にわたります。適切な対策を進めるためには、まず現在のAWS環境の設定状況を確認し、改善が必要な箇所を把握することが大切です。

NTT東日本では、AWS環境の情報セキュリティ設定を第三者の視点で点検する「クラウドセキュリティチェック for AWS」を提供しています。環境確認ツールと専任担当者による手動チェックを組み合わせて設定状況を確認するため、自社では気づきにくい設定上の課題の把握につながります。

具体的なチェック項目やサービス内容については、以下のページでご紹介していますので、ぜひご覧ください。

「クラウドセキュリティチェック for AWS」の詳細はこちら

3. AWSセキュリティのベストプラクティスを確認するチェックリスト

ここまで紹介した7領域を踏まえ、自社のAWS環境で確認しておきたい項目を5分野に整理しました。自社の設定状況を確認するための実務向けチェックリストとしてご活用ください。

• 横にスクロールします

未対応の項目がある場合は、扱うデータやシステムの重要度、想定される影響を確認し、優先順位をつけて改善しましょう。

チェックリストで未対応の項目が見つかったものの、どこから改善すべきか判断に迷う場合は、NTT東日本の「クラウドセキュリティチェック for AWS」をご活用ください。AWS環境の設定状況を第三者の視点で点検し、改善に向けた情報セキュリティ対策をアドバイスします。

「クラウドセキュリティチェック for AWS」の詳細はこちら

4. AWSセキュリティのベストプラクティスを実践する際の注意点

AWSセキュリティのベストプラクティスは、すべての対策を一律に実装すればよいものではありません。扱うデータやシステムの重要度、法令・社内規程、利用するAWSサービスなどを踏まえ、自社のワークロードに必要な対策と優先順位を判断しましょう。

実際に対策を進める際は、以下の点にも注意が必要です。

4-1. 設定変更による影響を事前に検証する

設定を変更すると、システムが利用できなくなるなど、可用性や業務へ影響する場合があります。本番環境へ反映する前に検証し、問題が起きた場合に元へ戻す手順も用意してください。

4-2. 検出結果に対応できる運用体制を整える

Amazon GuardDutyやAWS Security Hubなどは、有効化するだけで十分ではありません。通知を受けたあと、誰が内容を調査し、対応方針を決めるのかを明確にし、必要な修復まで進められる運用体制を整えましょう。

4-3. 設定状況を継続的に見直す

AWSのサービスや推奨事項、自社のシステム構成は変化するため、設定状況を定期的に見直すことも大切です。新しいサービスの導入やシステム構成・権限の変更、インシデントの発生時には、定期点検の時期を待たずに確認しましょう。

5. NTT東日本の「クラウドセキュリティチェック for AWS」

AWSセキュリティのベストプラクティスを継続的に実践するには、現在の設定状況を把握し、必要に応じて見直す必要があります。AWS環境の設定状況を客観的に確認したい場合は、NTT東日本の「クラウドセキュリティチェック for AWS」をご検討ください。

「クラウドセキュリティチェック for AWS」は、運用中のAWS環境における情報セキュリティ設定を、第三者の視点で確認するサービスです。AWS CIS Foundations Benchmarkなどに基づくチェックリストを使用し、環境確認ツールによる確認と専任担当者による手動チェックを組み合わせて点検します。

事前ヒアリングでAWSの利用状況と確認内容を整理したうえで、主に以下の設定を確認します。

• ルートユーザーやパスワードポリシーなど、IDとアクセス管理の設定
• AWS CloudTrailをはじめとするログ出力の設定
• 異常を検知した際のアラーム通知に関する設定
• 外部からの無防備なアクセスを許可していないかなど、ネットワークの設定
• 利用中のAWSサービスに応じた暗号化やアクセス保護などの設定

確認結果はパラメータシートへまとめ、設定上の課題や改善策をリモート会議で説明します。結果に基づくセキュリティ設定の修正にも有償で対応しています。

AWS環境の構築をベンダーへ任せており、現在の設定を把握できていない場合や、社内にAWSの専門担当者がいない場合にも有効です。自社環境の課題を把握し、改善の優先順位を明確にしたい方は、ぜひ以下のサービス資料をご覧ください。

クラウドセキュリティチェック for AWSの資料をダウンロードする

6. AWSセキュリティのベストプラクティスに関するよくある質問

AWSセキュリティのベストプラクティスに関して、よくある疑問へ回答します。

6-1. AWSのセキュリティ対策は何から始めるべきですか？

まず、情報セキュリティの責任者と管理対象を明確にし、利用しているAWSアカウントやサービス、データを把握します。そのうえで、ルートユーザーの保護やMFA、最小権限の適用、操作ログの取得、外部への公開範囲など、基本的な設定を確認しましょう。

すべての対策を実施することが難しい場合は、想定されるリスクと事業への影響を踏まえて優先順位を決め、順番に改善しましょう。

6-2. AWSのセキュリティ設定はどのくらいの頻度で見直すべきですか？

すべての企業に共通する一律の頻度はありません。扱うデータやシステムの重要度、変更の多さなどに応じて、月次や四半期など自社に適した確認頻度を定めましょう。重要なアカウントや外部公開設定など、リスクの高い項目はより短い間隔で確認するとよいでしょう。

新しいAWSサービスの導入時やシステム構成・権限の変更時、インシデントの発生後などには、定期点検の時期を待たずに見直してください。

6-3. AWS Security Hubを有効化すれば十分ですか？

AWS Security Hubを有効化するだけで、すべてのセキュリティリスクに対応できるわけではありません。AWS Security Hubは、複数のAWSセキュリティサービスから得られる検出結果を集約・関連付けし、重要なセキュリティ上の問題を把握して対応につなげるためのサービスです。

検出された問題については、内容を確認し、必要な対策を進める必要があります。AWS Security Hubを活用しながら、自社の環境に応じて設定や権限を見直し、継続的に改善することが重要です。

AWS環境の設定状況を第三者の視点でも確認したい場合は、NTT東日本の「クラウドセキュリティチェック for AWS」をご活用ください。ツールと専任担当者による手動チェックを組み合わせてAWS環境の設定を点検し、その結果をもとに情報セキュリティ対策をアドバイスします。

クラウドセキュリティチェック for AWSの資料をダウンロードする

7. AWSセキュリティのベストプラクティスを継続的に実践しよう

AWS Well-Architected Frameworkのセキュリティの柱では、安全なワークロードを設計・運用するための考え方と、具体的な対策を検討する7つの領域が示されています。

AWSの責任共有モデルを理解したうえで、IDとアクセス権限、ログ監視、インフラストラクチャやデータの保護など、自社のAWS環境に必要な対策を整理し、優先順位をつけて取り組みましょう。また、インシデント発生時の対応や開発段階からの対策もあらかじめ検討しておくことが大切です。

情報セキュリティ対策は、サービスや機能を導入して終わりではありません。検出結果への対応や、権限・設定の点検を継続し、自社のAWS環境やリスクの変化に合わせて改善していきましょう。

AWSセキュリティのベストプラクティスに沿った運用を続けていくためには、定期的に設定状況を確認し、必要な対策へつなげましょう。NTT東日本の「クラウドセキュリティチェック for AWS」では、クラウド利用のベストプラクティスに基づくチェックリストを用いてAWS環境を点検し、チェック結果をレポートでご説明します。

AWS環境の設定に見落としがないか確認したい方や、具体的にどのような項目を点検できるのか知りたい方は、ぜひサービス資料をご覧ください。

クラウドセキュリティチェック for AWSの資料をダウンロードする