# セキュリティ **Topics** + [セキュリティの基礎](a-sec-security.md) + [ID とアクセス管理](a-identity-and-access-management.md) + [検知](a-detective-controls.md) + [インフラストラクチャ保護](a-infrastructure-protection.md) + [データ保護](a-data-protection.md) + [インシデント対応](a-incident-response.md) # セキュリティの基礎 **Topics** + [SEC 1 ワークロードを安全に運用するには、どうすればよいですか?](w2aac19b7b5b5.md) # SEC 1 ワークロードを安全に運用するには、どうすればよいですか? ワークロードを安全に運用するには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。組織レベルおよびワークロードレベルにおいて、「運用上の優秀性」で定義した要件とプロセスを抽出し、それらをすべての領域に適用します。AWS や業界のレコメンデーションおよび脅威インテリジェンスを最新に保つことで、脅威モデルと管理目標を進化させることができます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティオペレーションを拡張できます。 **Topics** + [SEC01-BP01 アカウントを使用してワークロードを分ける:](sec_securely_operate_multi_accounts.md) + [SEC01-BP02 AWS アカウント をセキュリティ保護する](sec_securely_operate_aws_account.md) + [SEC01-BP03 管理目標を特定および検証する:](sec_securely_operate_control_objectives.md) + [SEC01-BP04 セキュリティ脅威に関する最新情報を入手する:](sec_securely_operate_updated_threats.md) + [SEC01-BP05 セキュリティに関する推奨事項を常に把握する](sec_securely_operate_updated_recommendations.md) + [SEC01-BP06 パイプラインのセキュリティコントロールのテストと検証を自動化する](sec_securely_operate_test_validate_pipeline.md) + [SEC01-BP07 脅威モデルを使用してリスクを特定し、優先順位を付ける](sec_securely_operate_threat_model.md) + [SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する](sec_securely_operate_implement_services_features.md) # SEC01-BP01 アカウントを使用してワークロードを分ける: セキュリティとインフラストラクチャを念頭に置いて、ワークロードが増大するにつれて組織が共通のガードレールを設定できるようにします。このアプローチによって、ワークロード間の境界と制御が確立します。開発環境およびテスト環境から本番環境を分離する場合、または外部コンプライアンス要件 (PCI-DSS や HIPAA など) で定義されている機密レベルの異なるデータを処理するワークロードとそうでないワークロードとの間に強力な論理的境界を設ける場合は、アカウントレベルの分離を強くお勧めします。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS Organizations を使用する: AWS Organizations を使用し、複数の AWS アカウント にポリシーベースの管理を一元的に適用します。 + [AWS Organizations の開始方法 ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html) + [サービスコントロールポリシーを使用して、AWS Organization のアカウント間にアクセス許可ガードレールを設定する方法 ](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) + AWS Control Tower を考慮する: AWS Control Tower では、ベストプラクティスに基づいて、新しいセキュアなマルチアカウントの AWS 環境を容易にセットアップおよび管理できます。 + [AWS Control Tower](https://aws.amazon.com/controltower/) ## リソース **関連するドキュメント:** + [IAM ベストプラクティス ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html?ref=wellarchitected) + [セキュリティ速報](https://aws.amazon.com/security/security-bulletins) + [AWS セキュリティ監査のガイドライン](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html?ref=wellarchitected) **関連動画:** + [Managing Multi-Account AWS Environments Using AWS Organizations (AWS Organizations を使用したマルチアカウント AWS 環境の管理) ](https://youtu.be/fxo67UeeN1A) + [Well-Architected の手法によるセキュリティのベストプラクティス ](https://youtu.be/u6BCVkXkPnM) + [Using AWS Control Tower to Govern Multi-Account AWS Environments (AWS Control Tower を使用したマルチアカウント AWS 環境の統制) ](https://youtu.be/2t-VkWt0rKk) # SEC01-BP02 AWS アカウント をセキュリティ保護する AWS アカウント のセキュリティ保護には、 [ルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)の保護および使用の回避、連絡先情報を最新の状態に保つなど、さまざまな側面があります。専用のインフラストラクチャで [AWS Organizations](https://aws.amazon.com/organizations/) AWS を使用すれば、ワークロードの拡大やスケーリングに合わせて、アカウントを一元管理できます。AWS Organizations は、アカウント全体の管理、制御の設定、サービスの構築に役立ちます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS Organizations を使用する: AWS Organizations を使用し、複数の AWS アカウント にポリシーベースの管理を一元的に適用します。 + [AWS Organizations の開始方法](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html) + [サービスコントロールポリシーを使用して、AWS Organization のアカウント間に許可ガードレールを設定する方法 ](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) + AWS ルートユーザーの使用を制限する: 特定のルートユーザーを必要とするタスクについては、当該ルートユーザーのみを使用します。 + [AWS アカウントのルートユーザー認証情報を必要とする AWS タスク ](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html) + ルートユーザー用の AWS Multi-Factor Authentication (AWS MFA): AWS Organizations が代理でルートユーザーを管理していない場合、AWS アカウント ルートユーザーで MFA を有効化します。 + [ルートユーザー ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user_manage_mfa) + ルートユーザーパスワードを定期的に変更する: ルートユーザーのパスワードを変更することにより、保存したパスワードが使用できる状態となっていることによるリスクが軽減されます。これは、AWS Organizations を使用しておらず、あらゆるユーザーが物理的にアクセスできる場合に特に重要です。 + [AWS アカウント のルートユーザーのパスワードの変更 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_change-root.html) + AWS アカウント のルートユーザーが使用された場合に通知を有効化する: 通知を受け取ることで、リスクは自動的に軽減されます。 + [AWS アカウント のルートアクセスキーを使用した場合の通知方法 ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/) + 新しく追加されたリージョンへのアクセスを制限する: 新しい AWS リージョン について、ユーザーやロールなどの IAM リソースは、有効にしたリージョンのみに伝播されます。 + [ 今後の AWS リージョン に対してアカウントを有効にするアクセス許可の設定 ](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/) + AWS CloudFormation StackSets を検討する: CloudFormation StackSets を使用すると、IAM ポリシー、ロール、グループなどのリソースをさまざまな AWS アカウント とリージョンに承認されたテンプレートからデプロイできます。 + [ CloudFormation StackSets を使用する ](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/) ## リソース **関連するドキュメント:** + [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) + [AWS セキュリティ監査ガイドライン ](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) + [ IAM ベストプラクティス ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [セキュリティ速報 ](https://aws.amazon.com/security/security-bulletins/) **関連動画:** + [ 自動化とガバナンスにより AWS の大規模な採用を可能にする ](https://youtu.be/GUMSgdB-l6s) + [ Well-Architected の手法によるセキュリティのベストプラクティス ](https://youtu.be/u6BCVkXkPnM) **関連する例:** + [ ラボ: AWS アカウント およびルートユーザー ](https://youtu.be/u6BCVkXkPnM) # SEC01-BP03 管理目標を特定および検証する: 脅威モデルから特定されたコンプライアンス要件とリスクに基づいて、ワークロードに適用する必要がある管理目標および管理を導き出し、検証します。管理目標と制御を継続的に検証することは、リスク軽減の効果測定に役立ちます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + コンプライアンス要件を特定する: ワークロードが準拠する必要のある組織要件、法的要件、規制要件を確認します。 + AWS コンプライアンスリソースを特定する: コンプライアンスを支援するために使用できる AWS のリソースを特定します。 + [https://aws.amazon.com/compliance/ ](https://aws.amazon.com/compliance/) + [ https://aws.amazon.com/artifact/](https://aws.amazon.com/artifact/) ## リソース **関連するドキュメント:** + [AWS セキュリティ監査のガイドライン](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) + [ セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) **関連動画:** + [AWS Security Hub CSPM: Manage Security Alerts and Automate Compliance](https://youtu.be/HsWtPG_rTak) + [Well-Architected の手法によるセキュリティのベストプラクティス](https://youtu.be/u6BCVkXkPnM) # SEC01-BP04 セキュリティ脅威に関する最新情報を入手する: 適切な制御を定義して実装するために、最新のセキュリティ脅威を常に把握して攻撃ベクトルを認識します。AWS Managed Services を利用することで、AWS アカウントにおける予期しない動作や異常な動作の通知を簡単に受けることができます。セキュリティ情報フローの一環として、AWS Partner ツールまたはサードパーティーの脅威情報フィードの利用を検討します。それらの [共通脆弱性識別子 (CVE) リスト ](https://cve.mitre.org/) には、一般に公開されているサイバーセキュリティの脆弱性が含まれており、最新の情報を入手するために利用することができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + 脅威インテリジェンスソースを購読する: ワークロードで使用しているテクノロジーに関連する、複数のソースからの脅威インテリジェンス情報を定期的に確認します。 + [共通脆弱性識別子リスト ](https://cve.mitre.org/) + 検討 [AWS Shield Advanced](https://aws.amazon.com/shield/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) サービスを検討する: ワークロードがインターネットに接続できる環境であれば、インテリジェンスソースをほぼリアルタイムで可視化することができます。 ## リソース **関連するドキュメント:** + [AWS セキュリティ監査のガイドライン](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) + [AWS Shield](https://aws.amazon.com/shield/) + [ セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) **関連動画:** + [Well-Architected の手法によるセキュリティのベストプラクティス ](https://youtu.be/u6BCVkXkPnM) # SEC01-BP05 セキュリティに関する推奨事項を常に把握する AWS と業界の両方のセキュリティの推奨事項を常に最新に保ち、ワークロードのセキュリティ体制を進化させます。[AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc&awsf.bulletins-year=year%232009) は、セキュリティおよびプライバシー通知に関する重要な情報を含みます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS のアップデートをフォローする: 購読または定期的にチェックして、新しい推奨事項や ヒント、テクニックを確認しましょう。 + [AWS Well-Architected ラボ](https://wellarchitectedlabs.com/?ref=wellarchitected) + [AWS セキュリティブログ](https://aws.amazon.com/blogs/security/?ref=wellarchitected) + [AWS のサービスドキュメント](https://aws.amazon.com/documentation/?ref=wellarchitected) + 業界ニュースを購読する: 複数のソースから、ワークロードで使用しているテクノロジーに関連するニュースフィードを定期的に確認します。 + [例: 共通脆弱性識別子リスト](https://cve.mitre.org/cve/?ref=wellarchitected) ## リソース **関連するドキュメント:** + [セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) **関連動画:** + [Well-Architected の手法によるセキュリティのベストプラクティス](https://youtu.be/u6BCVkXkPnM) # SEC01-BP06 パイプラインのセキュリティコントロールのテストと検証を自動化する ビルド、パイプライン、プロセスの一環としてテストおよび検証されるセキュリティメカニズムの安全なベースラインとテンプレートを確立します。ツールとオートメーションを使用して、すべてのセキュリティコントロールの継続的なテストと検証を実施します。たとえば、マシンイメージやインフラストラクチャなどの項目をコードテンプレートとしてスキャンして、セキュリティの脆弱性、不規則性、ドリフトを各ステージで確立されたベースラインから確認します。AWS CloudFormation Guard を使用すると、CloudFormation が安全なことを検証し、時間を節約し、設定エラーのリスクを低減するのに役立ちます。 本番環境に取り込まれるセキュリティの誤設定の数を減らすことが非常に重要です。ビルドプロセスでより適切な品質管理をより多く実行し、欠陥の数を減らすことができれば、より優れたものになります。継続的インテグレーションおよび継続的デプロイ (CI/CD) のパイプラインは、可能な限りセキュリティの問題をテストできるように設計する必要があります。CI/CD パイプラインは、ビルドと配信の各段階でセキュリティを強化する機会を提供します。CI/CD セキュリティツールも更新して、進化する脅威を軽減する必要があります。 ワークロード設定への変更をトラッキングして、監査、変更管理、および該当する可能性がある調査へのコンプライアンスに役立てます。AWS Config を使用して、AWS およびサードパーティーリソースを記録および評価できます。これにより、ルールやコンフォーマンスパックへの全体的なコンプライアンスを継続的に監査および評価できます。コンフォーマンスパックとは、是正措置に関する一連のルールのことです。 変更トラッキングには、組織の変更管理プロセス (MACD-Move/Add/Change/Delete とも呼ばれる) の一部である計画されていた変更、予定外の変更、インシデントなどの予期しない変更を含める必要があります。変更はインフラストラクチャで発生する場合もあれば、コードリポジトリの変更、マシンイメージおよびアプリケーションインベントリの変更、プロセスとポリシーの変更、ドキュメントの変更などの他のカテゴリに関連するものである場合もあります。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 設定管理を自動化する: 設定管理サービスまたはツールを使用して、リモートでアクションを実行し、安全な設定を自動的に適用および検証します。 + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) + [AWS で CI/CD パイプラインを設定する ](https://aws.amazon.com/getting-started/projects/set-up-ci-cd-pipeline/) ## リソース **関連するドキュメント:** + [How to use service control policies to set permission guardrails across accounts in your AWS Organization](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) **関連動画:** + [Managing Multi-Account AWS Environments Using AWS Organizations](https://youtu.be/fxo67UeeN1A) + [Well-Architected の手法によるセキュリティのベストプラクティス](https://youtu.be/u6BCVkXkPnM) # SEC01-BP07 脅威モデルを使用してリスクを特定し、優先順位を付ける 脅威モデルを使用して潜在的な脅威を特定し、その登録を最新の状態に維持します。脅威に優先順位を付け、セキュリティコントロールを調整して防止、検出、対応を行います。進化するセキュリティ環境の状況に応じてセキュリティコントロールを再確認および維持します。 脅威のモデル化は、設計プロセスの早い段階でセキュリティ上の問題を発見して対処するのを支援する体系的なアプローチを提供します。ライフサイクルの後半に緩和策を講じるよりも、早い段階で緩和策を講じた方がコストがかからないからです。 脅威のモデル化の典型的なコアステップは次のとおりです。 1. アセット、アクター、エントリポイント、コンポーネント、ユースケース、信頼レベルを特定し、これらを設計図に記載する。 1. 脅威のリストを特定する。 1. 各脅威について、セキュリティコントロールの実装を含む緩和策を特定する。 1. リスクマトリックスを作成し、脅威が適切に緩和されているかどうかを確認する。 脅威のモデル化は、ワークロード (またはワークロードの機能) レベルで行うのが最も効果的であり、すべてのコンテキストが評価に利用できることを保証します。セキュリティ状況の変化に応じて、このマトリックスを見直し、維持してください。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + 脅威モデルを作成する: 脅威モデルは、潜在的なセキュリティ脅威を特定して対処するのに役立ちます。 + [NIST: Guide to Data-Centric System Threat Modeling (データ中心システム脅威のモデル化へのガイド) ](https://csrc.nist.gov/publications/detail/sp/800-154/draft) ## リソース **関連するドキュメント:** + [AWS セキュリティ監査のガイドライン ](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) + [セキュリティ速報 ](https://aws.amazon.com/security/security-bulletins/) **関連動画:** + [Well-Architected の手法によるセキュリティのベストプラクティス](https://youtu.be/u6BCVkXkPnM) # SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する ワークロードのセキュリティ体制を進化させることができる、AWS および AWS パートナーのセキュリティサービスと機能を評価および実装します。AWS セキュリティブログは、新しい AWS サービスおよび機能、実装ガイド、および一般的なセキュリティガイダンスを取り上げます。[「AWS の最新情報」](https://aws.amazon.com/new) は、すべての AWS 機能、サービス、および発表に関する最新情報を確認する優れた方法です。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス + 定期的なレビューを計画する: コンプライアンス要件、AWS の新しいセキュリティ機能とセキュリティサービスの評価、業界の最新ニュースの入手を含むレビューアクティビティのカレンダーを作成します。 + AWS のサービスと機能について調べる: 使用中のサービスで利用可能なセキュリティ機能について調べ、新しい機能がリリースされた時には、それについて確認します。 + [AWS セキュリティブログ](https://aws.amazon.com/blogs/security/) + [AWS セキュリティ速報 ](https://aws.amazon.com/security/security-bulletins/) + [AWS のサービスドキュメント ](https://aws.amazon.com/documentation/) + AWS のサービスの導入プロセスを定義する: 新しい AWS サービスの導入プロセスを定義します。新しい AWS のサービスの機能とワークロードのコンプライアンス要件を評価する方法を含めます。 + 新しいサービスと機能をテストする: 新しいサービスと機能がリリースされたら、本稼働環境に近いかたちで複製する本稼働環境ではない環境でテストします。 + その他の防御メカニズムを実装する: ワークロードを保護するための自動化されたメカニズムを実装し、利用可能なオプションを確認します。 + [AWS Config ルール による非準拠 AWS リソースの修復 ](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) ## リソース **関連動画:** + [Well-Architected の手法によるセキュリティのベストプラクティス ](https://youtu.be/u6BCVkXkPnM) # ID とアクセス管理 **Topics** + [SEC 2 人とマシンの認証の管理はどのようにすればよいですか?](w2aac19b7b7b5.md) + [SEC 3 人とマシンのアクセス許可はどのように管理すればよいでしょうか?](w2aac19b7b7b7.md) # SEC 2 人とマシンの認証の管理はどのようにすればよいですか? AWS ワークロードを安全に運用するには、2 種類の ID を管理する必要があります。管理およびアクセス権を付与する必要があるアイデンティティのタイプを理解することで、適切な ID が適切な条件下で適切なリソースにアクセスできるようになります。 ユーザー ID: 管理者、開発者、オペレーター、エンドユーザーは、AWS 環境とアプリケーションにアクセスするために ID を必要とします。これらは、組織のメンバー、または共同作業を行う外部ユーザーであり、ウェブブラウザ、クライアントアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースを操作する人たちです。 マシン ID: サービスアプリケーション、運用ツール、ワークロードには、データの読み取りなどのために、AWS のサービスにリクエストを送信するための ID が必要です。このような ID には、Amazon EC2 インスタンスや AWS Lambda 関数など、AWS 環境で実行されているマシンが含まれます。また、アクセスを必要とする外部関係者のマシン ID を管理することもできます。さらに、AWS 環境にアクセスする必要があるマシンが AWS 外にある場合もあります。 **Topics** + [SEC02-BP01 強力なサインインメカニズムを使用する](sec_identities_enforce_mechanisms.md) + [SEC02-BP02 一時的な認証情報を使用する](sec_identities_unique.md) + [SEC02-BP03 シークレットを安全に保存して使用する](sec_identities_secrets.md) + [SEC02-BP04 一元化された ID プロバイダーを利用する](sec_identities_identity_provider.md) + [SEC02-BP05 定期的に認証情報を監査およびローテーションする](sec_identities_audit.md) + [SEC02-BP06 ユーザーグループと属性を活用する](sec_identities_groups_attributes.md) # SEC02-BP01 強力なサインインメカニズムを使用する パスワードに最小の長さを設定し、よくあるパスワードや再利用を避けるようにユーザーを教育します。ソフトウェアまたはハードウェアのメカニズムを使用した Multi-Factor Authentication (MFA) を強制して、検証を追加します。例えば、IAM アイデンティティセンターをアイデンティティソースとして使用する場合、MFA の「コンテキストアウェア」または「常時オン」設定でユーザーに独自の MFA デバイスの登録を許可すると、すばやく使用開始できます。外部の ID プロバイダー (IdP) を使用する場合は、IdP を MFA 用に設定します。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + MFA サインインを強制するアクセス管理 (IAM) ポリシーを作成する: ユーザーが [マイセキュリティ資格情報] ページでロールを引き受け、自分の認証情報を変更し、MFA デバイスを管理できるようにするものを除いて、すべての IAM アクションを禁止するカスタマー管理 IAM ポリシーを [作成します](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1). + ID プロバイダーで MFA を有効にする: [MFA](https:/aws.amazon.com/iam/details/mfa) を、アイデンティティプロバイダーや使用する [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/step1.html)などのシングルサインオンサービスで有効にします。 + 強力なパスワードポリシーを設定する: [強力なパスワードポリシーを](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html?ref=wellarchitected) IAM やフェデレーテッド ID システムで設定して、総当たり攻撃から守ります。 + [認証情報を定期的にローテーションする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials): ワークロードの管理者が、パスワードとアクセスキー (使用されている場合) を定期的に変更するようにします。 ## リソース **関連するドキュメント:** + [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html?ref=wellarchitected) + [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html?ref=wellarchitected) +  [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html?ref=wellarchitected) + [セキュリティパートナーソリューション: アクセスおよびアクセスコントロール](https://aws.amazon.com/security/partner-solutions/#access-control) + [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) + [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) **関連動画:** + [シークレットを大規模に管理、取得、変更するためのベストプラクティス](https://youtu.be/qoxxRlwJKZ4) + [IAM Identity Center を使用した大規模なユーザー権限の管理](https://youtu.be/aEIqeFCcK7E) + [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP02 一時的な認証情報を使用する ID を要求して一時的な認証情報を [動的に取得します](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html).ワークフォース ID の場合、AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) ロールとのフェデレーションを使用して AWS アカウント にアクセスします。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや AWS Lambda 関数などのマシン ID の場合、長期的なアクセスキーを持つ IAM ユーザーではなく IAM ロールを使用する必要があります。 AWS マネジメントコンソール を使用するユーザー ID の場合、ユーザーは一時的な認証情報の取得と AWS へのフェデレーションが必要です。これは、AWS IAM アイデンティティセンター ユーザーポータルを使用して実行できます。CLI アクセスを必要とするユーザーの場合は、 [AWS CLI v2](http://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-generally-available/)(IAM Identity Center との直接統合をサポートする) を使用していることを確認してくださいユーザーは、IAM アイデンティティセンターアカウントおよびロールにリンクされた CLI プロファイルを作成できます。CLI は AWS の認証情報を IAM Identity Center から自動的に取得し、ユーザーに代わってその情報を更新します。これにより、 コンソールから一時的な AWS の認証情報をコピーして貼り付ける作業を省略できます。SDK については、ユーザーは AWS Security Token Service (AWS STS) を使用して、一時的な認証情報を取得するロールを引き受ける必要があります。場合によって、一時的な認証情報が使用できないこともあります。アクセスキーを保存するリスクに注意しながら頻繁に更新し、可能なら多要素認証 (MFA) を条件として設定する必要があります。最後に評価した情報を使って、アクセスキーを変更または削除するタイミングを決定します。 AWS リソースへのアクセス権を一般ユーザーに付与する必要がある場合は、 [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html) ID プールを使用して、AWS リソースにアクセスするための、権限が制限されている一時的な認証情報のセットを割り当てます。各ユーザーの権限は、作成した [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) で制御されます。ユーザーのロールを選択するルールは、ユーザーの ID トークンの登録に基づいて定義します。認証済みユーザーにはデフォルトのロールを定義します。認証されていないゲストユーザーには、制限付きのアクセス権限を持つ IAM ロールを個別に定義できます。 マシン ID に AWS へのアクセス許可を付与するには IAM ロールが必要です。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの場合は、 [Amazon EC2 用のロールを使用できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).IAM ロールを Amazon EC2 インスタンスにアタッチすると、Amazon EC2 で実行されているアプリケーションは、AWS がインスタンスメタデータサービス (IMDS) を通して自動的に作成、配布、ローテーションする一時的なセキュリティ認証情報を使用できるようになります。それらの [IMDS の最新バージョンを](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/) 使用すると、臨時の認証情報を公開する脆弱性から保護できるため、実装する必要があります。キーまたはパスワードを使用して Amazon EC2 インスタンスにアクセスする場合、[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、保存されたシークレットなしで、インストール済みエージェントを使用してインスタンスにアクセスし管理するためのより安全な方法として使用できます。さらに、AWS Lambda などの AWS のサービスでは、IAM サービスロールを設定して、一時的な認証情報でサービスに AWS アクションを実行する権限を与えることができます。臨時の認証情報を使用できない状況では、 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)のようなプログラムツールを使って、認証情報の変更と管理を自動化します。 **定期的に認証情報を監査およびローテーションする: **正しい制御が実施されていることを確認するには、定期的な検証、できれば自動化されたツールによる検証が必要です。ユーザー ID の場合、ユーザーにはパスワードの定期的な変更と、一時的な認証情報を優先したアクセスキーの削除を要求する必要があります。IAM ユーザーから一元化されたアイデンティティに移行しているため、 [認証情報レポートを生成して ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)IAM ユーザーを監査できます。また、ID プロバイダーの MFA 設定を矯正することを推奨します。次の [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) をセットアップして、これらの設定をモニタリングできます。マシン ID の場合、IAM ロールを使用した一時的な認証情報を使用する必要があります。それが不可能なときは、アクセスキーの監査および更新の頻度を高めることが重要です。 **シークレットを安全に保存して使用する:** IAM に関連せず、臨時認証情報を利用できない認証情報 (データベースのログインなど) については、シークレット管理用に設計されたサービス [Secrets Manager](https://aws.amazon.com/secrets-manager/)。Secrets Manager では、サポートされているサービスを使用して、暗号化されたシークレットの管理、ローテーション、安全な保管を簡単に [行うことができます](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html).シークレットにアクセスするための呼び出しは、監査用に AWS CloudTrail に記録されます。IAM のアクセス許可を使用すれば、それに最小権限のアクセス許可を付与することが可能です。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + 最小権限ポリシーを実装する: IAM グループおよびロールに最小権限のアクセスポリシーを割り当てて、定義したユーザーのロールまたは機能を反映します。 + [最小権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) + 必要でないアクセス許可を削除する: 不要なアクセス許可を削除して、最小権限を実装します。 + [ユーザーアクティビティを確認してポリシーの範囲を削減する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) + [ロールアクセスを表示する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#roles-delete_prerequisites) + アクセス許可の境界を考慮する: アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する管理ポリシーを使用するための高度な機能です。エンティティのアクセス許可の境界では、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。 + [ラボ: ロールの作成を委任する IAM アクセス許可境界](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html) + アクセス許可のリソースタグを検討する: タグを使用して、タグ付けをサポートする AWS リソースへのアクセスを制御できます。また、IAM ユーザーとロールにタグ付けして、ユーザーがアクセスできる内容を制御することもできます。 + [ラボ: EC2 の IAM タグベースのアクセスコントロール](https://wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) + [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) ## リソース **関連するドキュメント:** + [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [セキュリティパートナーソリューション: アクセスおよびアクセスコントロール](https://aws.amazon.com/security/partner-solutions/#access-control) + [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) + [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) **関連動画:** + [シークレットを大規模に管理、取得、変更するためのベストプラクティス](https://youtu.be/qoxxRlwJKZ4) + [AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理](https://youtu.be/aEIqeFCcK7E) + [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP03 シークレットを安全に保存して使用する サードパーティー製アプリケーションのパスワードなど、シークレットを必要とするユーザー ID とマシン ID については、最新の業界標準を用いた自動ローテーションで保管します。IAM に関連せず、データベースのログインなど一時的な認証情報を活用できないものについては、AWS Secrets Manager のようなシークレットの管理に対応したサービスを使用します。Secrets Manager では、サポートされているサービスを使用して、暗号化されたシークレットの管理、ローテーション、安全な保管を簡単に行うことができます。 シークレットにアクセスするための呼び出しは、監査用に AWS CloudTrail に記録されます。IAM 権限により、最小限の権限でアクセスできるようにすることができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS Secrets Manager を使用する: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、機密情報の管理を容易にする AWS のサービスです。シークレットとは、データベース認証情報、パスワード、サードパーティ API キー、任意のテキストなどです。 ## リソース **関連するドキュメント:** + [AWS Secrets Manager の開始方法 ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) **関連動画:** + [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4) # SEC02-BP04 一元化された ID プロバイダーを利用する ユーザー ID の場合、ID を一元管理できる ID プロバイダーを利用します。一つの場所から権限の作成、管理、取り消しを行うため、複数のアプリケーションおよびサービスに影響する権限を効率的に管理できます。たとえば誰かが組織を離れる場合、すべてのアプリケーションとサービス (AWS を含む) へのアクセスを一つの場所で取り消すことができます。これにより、複数の認証情報を用意する必要性がなくなり、既存の人事 (HR) プロセスと統合できる可能性が生まれます。 AWS の個別アカウントのフェデレーションでは、AWS Identity and Access Management を使った SAML 2.0 ベースのプロバイダーで AWS の一元化された ID を使用できます。SAML 2.0 プロトコルと互換性のあるプロバイダーであればいずれも使用できます。AWS でホストされているかどうか、AWS 外部にあるかどうか、AWS Partner パートナーネットワーク (APN) から提供されているかどうかは問いません [SAML 2.0 ベースのプロバイダーで、](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html) 。AWS アカウントと選択したプロバイダーのフェデレーションを使用して、SAML アサーションで一時的なセキュリティ認証情報を取得すれば、ユーザーまたはアプリケーションに AWS API オペレーションを呼び出すアクセス権限を付与できます。ウェブベースのシングルサインオンもサポートされており、ユーザーはサインインウェブサイトから AWS マネジメントコンソールにサインインできます。 AWS Organizations の複数のアカウントへのフェデレーションの場合は、 [AWS IAM アイデンティティセンター (IAM Identity Center) で ID ソースを設定して、](http://aws.amazon.com/single-sign-on/)ユーザーとグループの保存場所を指定できます。設定が完了すると、ID プロバイダーが信頼できる [ソースになり、](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) System for Cross-domain Identity Management (SCIM) v2.0プロトコルを利用して情報を同期できます。その後ユーザーまたはグループを検索し、AWS アカウントやクラウドアプリケーションへの IAM Identity Center アクセスを付与できます。 IAM Identity Center は AWS Organizations と統合され、ID プロバイダーを一度設定してから、 [組織で管理している既存および新規のアカウントへの](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html) アクセス権を付与できます。IAM Identity Center には、ユーザーとグループの管理に使用できるデフォルトストアがあります。IAM Identity Center ストアを使用する場合は、ユーザーとグループを作成してから、最小権限のベストプラクティスに基づきそのアクセスレベルを必要な AWS アカウントとアプリケーションに割り当てます。または、 [SAML 2.0 を利用して ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)外部の ID プロバイダーに [接続するか、](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) AWS Directory Service を使用して Microsoft AD ディレクトリに接続するかを選択できます。設定が完了したら、一元化された ID プロバイダーで認証すれば、AWS マネジメントコンソール、AWS モバイルアプリにサインインできるようになります。 モバイルアプリなどのワークロードのエンドユーザー管理には、 [Amazon Cognito](http://aws.amazon.com/cognito/)。このサービスには、ウェブおよびモバイルアプリケーションの認証、承認、ユーザー管理の機能があります。ユーザーは、ユーザー名とパスワードを使用して直接サインインするか、Amazon、Apple、Facebook、Google などのサードパーティーを通じてサインインできます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + 管理アクセスを一元化する: Identity and Access Management (IAM) アイデンティティプロバイダーエンティティを作成して、AWS アカウント とアイデンティティプロバイダー (IdP) 間に信頼される関係を確率します。IAM は、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートします。 + [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + アプリケーションアクセスを一元化する: アプリケーションアクセスの一元化には Amazon Cognito を考慮します。ユーザーのサインアップやサインイン、アクセスコントロールをモバイルアプリやウェブアプリに簡単に追加できます。 [Amazon Cognito](https://aws.amazon.com/cognito/) は、数百万人のユーザーに対応し、Facebook、Google、Amazon などのソーシャル ID プロバイダーや、SAML 2.0 によるエンタープライズ ID プロバイダーとのサインインをサポートします。 + 旧 IAM ユーザーおよびグループを削除する: ID プロバイダー (IdP) の使用を開始したら、不要になった IAM ユーザーとグループを削除します。 + [未使用の認証情報の検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) + [IAM グループの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) ## リソース **関連するドキュメント:** + [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [Security Partner Solutions: Access and Access Control (セキュリティパートナーソリューション: アクセスおよびアクセスコントロール)](https://aws.amazon.com/security/partner-solutions/#access-control) + [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) + [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) **関連動画:** + [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4) + [Managing user permissions at scale with AWS IAM アイデンティティセンター (AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理)](https://youtu.be/aEIqeFCcK7E) + [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP05 定期的に認証情報を監査およびローテーションする 一時的な認証情報に頼れず、長期的な認証情報が必要な場合は、認証情報を監査して、定義された管理方法、たとえば多要素認証 (MFA) が実施され、定期的にローテーションされ、アクセスレベルが適切であることを確認する必要があります。正しい制御が実施されていることを確認するには、定期的な検証、できれば自動化されたツールによる検証が必要です。ユーザー ID の場合、ユーザーにはパスワードの定期的な変更と、一時的な認証情報を優先したアクセスキーの削除を要求する必要があります。AWS Identity and Access Management (IAM) ユーザーから一元化されたアイデンティティに移行しているため、 [認証情報レポートを生成して ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)IAM ユーザーを監査できます。また、ID プロバイダーで MFA 設定を実施することをお勧めします。次の [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) をセットアップして、これらの設定をモニタリングできます。マシン ID の場合、IAM ロールを使用した一時的な認証情報を使用する必要があります。それが不可能なときは、アクセスキーの監査および更新の頻度を高めることが重要です。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 認証情報を定期的に監査する: 認証情報レポートと Access Management (IAM) Access Analyzer を使用して、IAM 認証情報とアクセス許可を監査します。 + [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) + [認証情報レポートの取得](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) + [ラボ: IAM ユーザーの自動クリーンアップ](https://wellarchitectedlabs.com/Security/200_Automated_IAM_User_Cleanup/README.html?ref=wellarchitected-tool) + アクセスレベルを使用して IAM アクセス許可を確認する: AWS アカウント のセキュリティを向上させるには、各 IAM ポリシーを定期的に確認してモニタリングします。ポリシーが、必要なアクションのみを実行するために必要な最小権限を付与していることを確認します。 + [アクセスレベルを使用して IAM アクセス許可を確認する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-access-levels-to-review-permissions) + IAM リソースの作成と更新の自動化を検討する: AWS CloudFormation を使用すると、テンプレートを検証してバージョンを管理できるため、ロールやポリシーを含む IAM リソースのデプロイを自動化して、人為的ミスを減らすことができます。 + [ラボ: IAM グループとロールの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_IAM_Groups_and_Roles/README.html) ## リソース **関連するドキュメント:** + [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [Security Partner Solutions: Access and Access Control (セキュリティパートナーソリューション: アクセスおよびアクセスコントロール)](https://aws.amazon.com/security/partner-solutions/#access-control) + [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) **関連動画:** + [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4) + [Managing user permissions at scale with AWS IAM アイデンティティセンター (AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理)](https://youtu.be/aEIqeFCcK7E) + [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc) # SEC02-BP06 ユーザーグループと属性を活用する 管理対象のユーザー数が増えるにつれて、大規模な管理ができるユーザー管理方法が必要となります。一般的なセキュリティ要件を持つユーザーを ID プロバイダーで定義したグループに分け、アクセスコントロールに使用される可能性のあるユーザー属性 (部署や場所など) を最新で正確な状態に保つメカニズムを導入します。アクセス制御には、個々のユーザーではなくこのグループと属性を使用します。こうすると、アクセス許可セットを使用してユーザーのグループメンバーシップや属性を一度変更するだけで [アクセスを一元管理でき、](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html)ユーザーのアクセスに変更が必要なときに多数のポリシーを個別に更新せずに済みます。ユーザーグループや属性の管理に AWS IAM アイデンティティセンター (IAM Identity Center)を使用できます。IAM Identity Center は、一般的に使用されている属性に対応しています。ユーザー作成時の手動入力も、クロスドメイン ID 管理システム (SCIM) 仕様などで定義された同期エンジンを使用した自動プロビジョニングも可能です。 一般的なセキュリティ要件を持つユーザーを ID プロバイダーで定義したグループに分け、アクセスコントロールに使用される可能性のあるユーザー属性 (部署や場所など) を最新で正確な状態に保つメカニズムを導入します。アクセスを制御するには、個々のユーザーではなくこれらのグループと属性を使用します。これにより、ユーザーのアクセスニーズが変化したときに多くの個別のポリシーを更新することなく、ユーザーのグループメンバーシップや属性を 1 回変更することで、アクセスを一元管理できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + AWS IAM アイデンティティセンター (IAM Identity Center)を使用している場合、グループを設定します: IAM Identity Center では、ユーザーのグループを設定し、必要なレベルのアクセス許可をグループに割り当てることができます。 + [AWS シングルサインオン - アイデンティティの管理](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) + 属性ベースのアクセスコントロール (ABAC) について学ぶ: ABAC は、属性に基づいてアクセス許可を定義する認証戦略です。 + [AWS の ABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [ラボ: EC2 の IAM タグベースのアクセスコントロール](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) ## リソース **関連するドキュメント:** + [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) + [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) + [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) **関連動画:** + [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4) + [Managing user permissions at scale with AWS IAM アイデンティティセンター (AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理)](https://youtu.be/aEIqeFCcK7E) + [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc) **関連する例:** + [ラボ: EC2 の IAM タグベースのアクセスコントロール](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) # SEC 3 人とマシンのアクセス許可はどのように管理すればよいでしょうか? アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。権限を分けることで、どのような条件で誰が何にアクセスできるかを制御します。 **Topics** + [SEC03-BP01 アクセス要件を定義する](sec_permissions_define.md) + [SEC03-BP02 最小特権のアクセスを付与します](sec_permissions_least_privileges.md) + [SEC03-BP03 緊急アクセスのプロセスを確立する](sec_permissions_emergency_process.md) + [SEC03-BP04 アクセス許可を継続的に削減する](sec_permissions_continuous_reduction.md) + [SEC03-BP05 組織のアクセス許可ガードレールを定義する](sec_permissions_define_guardrails.md) + [SEC03-BP06 ライフサイクルに基づいてアクセスを管理する](sec_permissions_lifecycle.md) + [SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](sec_permissions_analyze_cross_account.md) + [SEC03-BP08 リソースを安全に共有する](sec_permissions_share_securely.md) # SEC03-BP01 アクセス要件を定義する ワークロードの各コンポーネントまたはリソースには、管理者、エンドユーザー、またはその他のコンポーネントからアクセスする必要があります。各コンポーネントにアクセスできるユーザーや内容を明確に定義し、適切な ID タイプと認証および承認の方法を選択します。 **一般的なアンチパターン:** + シークレットをハードコーディングする、またはアプリケーション内に格納する + 各ユーザーにカスタムのアクセス許可を付与する + 永続的な認証情報を使用する **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス ワークロードの各コンポーネントまたはリソースには、管理者、エンドユーザー、またはその他のコンポーネントからアクセスする必要があります。各コンポーネントにアクセスできるユーザーや内容を明確に定義し、適切な ID タイプと認証および承認の方法を選択します。 組織内の AWS アカウントへの通常のアクセスは、 [フェデレーションアクセス](https://aws.amazon.com/identity/federation/) または一元化された ID プロバイダーを使用して提供する必要があります。また、アイデンティティ管理を一元化し、AWS へのアクセスを従業員のアクセスライフサイクルに統合するための確立されたプラクティスを整備する必要があります。例えば、従業員がアクセスレベルの異なる職種に異動するときは、そのグループメンバーシップも新しいアクセス要件を反映するように変更される必要があります。 非人間アイデンティティのアクセス要件を定義するときは、どのアプリケーションとコンポーネントがアクセスを必要としているか、またアクセス許可をどのように付与するかを決定します。お勧めのアプローチは、最小特権アクセスモデルで構築された IAM ロールを使用する方法です。[AWS マネージドポリシー](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) は、最も一般的なユースケースをカバーする定義済みの IAM ポリシーを提供します。 AWS のサービス ( [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) や [AWS Systems Manager パラメータストア) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)を使用すると、IAM ロールの使用が不可能なケースで、シークレットをアプリケーションやワークロードから安全に切り離すことができます。Secrets Manager では、認証情報の自動ローテーションを確立できます。Systems Manager でパラメータの作成時に指定した一意の名前を使用することで、スクリプト、コマンド、SSM ドキュメント、設定、オートメーションワークフロー内のパラメータを参照できます。 AWS Identity and Access Management Roles Anywhere を使用すると、 [IAM 内の一時的なセキュリティ認証情報を取得して、](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) AWS の外部で実行されるワークロードに使用できます。ワークロードに使用できる  [IAM ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) および  [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) は、AWS アプリケーションが AWS リソースにアクセスするために使用するものと同じです。 可能な場合は、長期の静的な認証情報よりも、短期の一時的な認証情報を優先します。IAM ユーザーに、プログラムによるアクセスと長期の認証情報を付与する必要がある場合は、 [最後に使用されたアクセスキーの情報を使用し、](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) アクセスキーのローテーションと削除を行います。 ## リソース **関連するドキュメント:** + [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/) + [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) + [AWS Managed policies for IAM Identity Center (IAM アイデンティティセンター用の AWS マネージドポリシー)](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) + [AWS IAM policy conditions (AWS IAM ポリシー条件)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) + [IAM ユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html) + [必要でない認証情報を削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) + [「IAM ポリシーを管理する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) + [How to control access to AWS resources based on AWS アカウント, OU, or organization (AWS アカウント、OU、または組織に基づいて AWS リソースへのアクセスを制御する方法)](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/) + [Identify, arrange, and manage secrets easily using enhanced search in AWS Secrets Manager (AWS Secrets Manager の拡張検索を使用してシークレットを容易に特定、調整、管理する)](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) **関連動画:** + [Become an IAM Policy Master in 60 Minutes or Less (60 分以内に IAM ポリシーマスターになる)](https://youtu.be/YQsK4MtsELU) + [Separation of Duties, Least Privilege, Delegation, and CI/CD (職務分離、最小特権、委任、および CI/CD)](https://youtu.be/3H0i7VyTu70) + [Streamlining identity and access management for innovation (アイデンティティとアクセスの管理を合理化してイノベーションを実現)](https://www.youtube.com/watch?v=3qK0b1UkaE8) # SEC03-BP02 最小特権のアクセスを付与します 特定の条件下で特定の AWS リソースに対する特定のアクションを許可して、アイデンティティに必要なアクセスのみを付与します。グループと ID 属性を利用して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じてアクセス許可を動的に設定します。たとえば、開発者のグループに、扱うプロジェクトのリソースのみを管理することを許可できます。これにより、開発者がグループから削除されると、アクセスポリシーに変更を加えることなく、そのグループがどこでアクセスコントロールに使用されたかを問わず、開発者のアクセスが取り消されます。 **一般的なアンチパターン:** + デフォルトでユーザーに管理者アクセス許可を付与する + ルートアカウントを日常業務に使用する **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス 最小権限の [原則を設定することで、](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 特定のタスクを実行するための必要最小限の機能セットのみを実行する許可が ID に与えられるようになり、使いやすさと効率のバランスを取ることができます。この原則を適用すると、意図しないアクセスは制限され、誰がどのリソースにアクセス権限があるかを監査できます。AWS では、ルートユーザー以外のアイデンティティは、デフォルトではアクセス許可を持ちません。ルートユーザーの認証情報は、厳重に制御し、 [特定のタスクにのみ使用する必要があります](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)。 ポリシーを使用して、フェデレーティッド ID、マシン、リソース (S3 バケットなど) が使用する IAM ロールなどの IAM またはリソースエンティティにアタッチされたアクセス許可を明示的に付与できます。ポリシーの作成およびアタッチでは、AWS がアクセスを許可するために必要なサービスアクション、リソース、条件を指定できます。AWS では、アクセスを最小限にするために役立つさまざまな条件を用意しています。例えば、 `PrincipalOrgID ` [条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を使用すると、AWS Organizations の識別子が検証されるため、AWS 組織内でアクセスを付与できます。 AWS のサービスがユーザーに代わって行うリクエスト (AWS CloudFormation による AWS Lambda 関数の作成など) を制御するには、 `CalledVia ` 条件キーを使用します。さまざまなポリシータイプを積み重ねて、アカウント内でアクセス許可すべてを効果的に制限する必要があります。例えば、アプリケーションチームが独自の IAM ポリシーを作成できるようにする一方、 [アクセス許可の境界](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) を使用して、そのチームが付与できる最大限のアクセス許可を制限できます。 アクセス許可の管理をスケールして最小特権の原則を遵守するのに役立つ AWS の機能がいくつかあります。[属性ベースのアクセスコントロール](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) では、リソースの *[タグ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)* に基づいてアクセス許可を制限できます。リソースに適用されるタグと呼び出し側の IAM プリンシパルに基づいた認可の決定が可能となります。それにより、タグ付けとアクセス許可ポリシーを組み合わせて、多数のカスタムポリシーを必要としない、きめ細かいリソースアクセスを実現できます。 また、最小特権ポリシーの作成を迅速に行うために、アクティビティの実行後に CloudTrail のアクセス許可に基づいてポリシーを作成することもできます。[IAM Access Analyzer は、アクティビティに基づいて IAM ポリシーを自動生成できます](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)。また、IAM アクセスアドバイザーを組織レベルまたは個々のアカウントレベルで使用して [最終アクセスの情報を追跡し、特定のポリシーを適用できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。 これらの詳細を確認して不必要なアクセス許可を削除する頻度を定めます。AWS 組織内でアクセス許可のガードレールを確立し、すべてのメンバーアカウント内で最大限のアクセス許可を制御する必要があります。例えば [AWS Control Tower などのサービスには、規範に基づいて管理される予防的コントロールが含まれており、](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 独自のコントロールを定義できます。 ## リソース **関連するドキュメント:** + [IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) + [Techniques for writing least privilege IAM policies (最小特権の IAM ポリシーを作成するテクニック)](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) + [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity (IAM Access Analyzer は、アクセスアクティビティに基づいて IAM ポリシーを生成することにより、最小特権のアクセス許可の実装を容易にする)](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) + [最終アクセス情報を使用した AWS のアクセス許可の調整](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) + [IAM でのポリシータイプと使用する状況](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) + [IAM Policy Simulator を使用した IAM ポリシーのテスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) + [AWS Control Tower のガードレール](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) + [Zero Trust architectures: An AWS perspective (ゼロトラストアーキテクチャ: AWS の視点)](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) + [How to implement the principle of least privilege with CloudFormation StackSets (CloudFormation StackSets を使用して最小特権の原則を実装する方法)](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) **関連動画:** + [Next-generation permissions management (次世代のアクセス許可管理)](https://www.youtube.com/watch?v=8vsD_aTtuTo) + [Zero Trust: An AWS perspective (ゼロトラスト: AWS の視点)](https://www.youtube.com/watch?v=1p5G1-4s1r0) + [How can I use permissions boundaries to limit IAM users and roles to prevent privilege escalation? (アクセス許可の境界を使用して IAM ユーザーとロールの範囲を限定し、権限の昇格を防ぐにはどうすればよいですか?)](https://www.youtube.com/watch?v=omwq3r7poek) **関連サンプル:** + [ラボ: ロールの作成を委任する IAM アクセス許可の境界](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html) # SEC03-BP03 緊急アクセスのプロセスを確立する 自動プロセスまたはパイプラインの問題が発生した場合に、ワークロードへの緊急アクセスを許可するプロセス。これにより、最小権限のアクセスを利用しながら、ユーザーは必要なときに適切なレベルのアクセスを取得できます。例えば、アクセス用の緊急 AWS クロスアカウントロール、または管理者が緊急リクエストの検証と承認を行う際の特定のプロセスなど、管理者がリクエストを確認して承認するプロセスを確立します。 **一般的なアンチパターン:** + 既存の ID 設定を使用して停止状態から復旧するための緊急プロセスを整備していない。 + トラブルシューティングや復旧の目的で長期昇格のアクセス許可を付与する。 **このベストプラクティスが確立されていない場合のリスクレベル:** 中 ## 実装のガイダンス 緊急アクセスの確立では、複数のケースに備える必要があります。まず、プライマリ ID プロバイダーの障害です。このケースでは、復旧のためのアクセス許可が必須となる第 2 のアクセス方法を用いる必要があります。この方法では、バックアップ ID プロバイダーまたは IAM ユーザーを使用できます。第 2 の方法が用いられる場合には、 [厳格に制御、監視され、通知する](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 必要があります。緊急アクセス ID は、この目的に固有のアカウントに属し、復旧に特化したロールを引き受けるためのアクセス許可のみを持つ必要があります。 また、緊急アクセスのために管理アクセス権の一時的な昇格が求められるケースにも備える必要があります。一般的なシナリオでは、変更のデプロイに使用される自動プロセスへのアクセス許可に変更を加えることを制限します。このプロセスで問題が発生した場合、ユーザーはアクセス許可を復元機能に昇格させることをリクエストしなければならない可能性があります。このケースでは、ユーザーがアクセス権の昇格をリクエストし、管理者が検証して承認することができるプロセスを確立します。アクセスの事前プロビジョニングと緊急の *break-glass* ロールの設定に関して、ベストプラクティスのガイダンスを説明する実装計画が含まれています [SEC10-BP05 アクセスを事前プロビジョニングする](sec_incident_response_pre_provision_access.md)。 ## リソース **関連するドキュメント:** + [Monitor and Notify on AWS (AWS アカウントのルートユーザーアクティビティの監視と通知)](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity) + [Managing temporary elevated access (アクセス権の一時的な昇格の管理)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) **関連動画：** + [Become an IAM Policy Master in 60 Minutes or Less (60 分以内に IAM ポリシーマスターになる)](https://youtu.be/YQsK4MtsELU) # SEC03-BP04 アクセス許可を継続的に削減する チームとワークロードが必要とするアクセスを決定したら、不要になったアクセス許可を削除し、最小権限のアクセス許可を達成するためのレビュープロセスを確立します。未使用の ID とアクセス許可を継続的にモニタリングし、削減します。 チームやプロジェクトが開始した直後には、イノベーションと俊敏性を引き出すため、幅広いアクセス権 (開発またはテスト環境で) の付与を選択する場合があります。アクセス権を継続的に評価し、必要な許可のみにアクセスを制限し、最小権限を付与することをお勧めします。AWS では、未使用のアクセス権を特定するのに役立つアクセス分析機能を提供しています。未使用のユーザー、ロール、アクセス許可、および認証情報を特定しやすくするため、AWS はアクセスアクティビティを分析し、最後に使用されたアクセスキーとロールの情報を提供します。最終アクセスタイムスタンプ [を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) と、 [未使用のユーザーとロールを識別し、](http://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/)それらを削除できます。さらに、サービスとアクションの最終アクセス時間情報を確認し、 [特定のユーザーおよびロールのアクセス許可を厳密に識別できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).たとえば、最終アクセス時間情報を使用して、アプリケーションロールが必要とする特定の Amazon Simple Storage Service (Amazon S3) アクションを特定し、それらのアクションのみにアクセスを制限できます。これらの機能は、AWS マネジメントコンソール およびプログラムで使用でき、インフラストラクチャワークフローや自動化ツールに組み込むことができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス + AWS Identity and Access Management (IAM) Access Analyzer を設定する: AWS IAM Access Analyzer は、Amazon Simple Storage Service (Amazon S3) バケットや IAM ロールなど、外部エンティティと共有されている組織のリソースとアカウントを特定するのに役立ちます。 + [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) ## リソース **関連するドキュメント:** + [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [最小権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) + [必要でない認証情報を削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) + [「IAM ポリシーを管理する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) **関連動画:** + [Become an IAM Policy Master in 60 Minutes or Less (60 分以内に IAM ポリシーマスターになる)](https://youtu.be/YQsK4MtsELU) + [Separation of Duties, Least Privilege, Delegation, and CI/CD (職務分離、最小特権、委任、および CI/CD)](https://youtu.be/3H0i7VyTu70) # SEC03-BP05 組織のアクセス許可ガードレールを定義する 組織内のすべての ID へのアクセスを制限する共通コントロールを確立します。例えば、特定の AWS リージョン へのアクセスを制限したり、中央セキュリティチームが使用する IAM ロールなどの一般的なリソースをオペレータが削除できないようにしたりできます。 **一般的なアンチパターン:** + ワークロードを組織の管理者アカウントで実行する + 本番稼動のワークロードと非本番稼動のワークロードを同じアカウントで実行する **このベストプラクティスが確立されていない場合のリスクレベル:** 中 ## 実装のガイダンス AWS で管理するワークロードの増加に伴い、アカウントを使用してワークロードを分離し、AWS Organizations を使用してそのアカウントを管理する必要があります。組織内のすべての ID へのアクセスを制限するために、共通のアクセス許可ガードレールの確立を推奨しています。例えば、特定の AWS リージョンへのアクセスを制限したり、中央セキュリティチームが使用する IAM ロールなどの共通リソースをチームのメンバーが削除できないようにしたりできます。 これを実行するには、ユーザーによるキーサービスの無効化を防止するなどの、サービスコントロールポリシーの例を実装します。SCP は IAM ポリシー言語を使用し、すべての IAM プリンシパル (ユーザーとロール) が遵守するコントロールを確立します。特定の条件に基づいて、特定のサービスアクションおよびリソースへのアクセスを制限することによって、組織のアクセスコントロールのニーズを満たすことができます。ガードレールには、必要に応じて例外を定義できます。例えば、アカウント内の特定の管理者ロールを除くすべての IAM エンティティに対して、サービスアクションを制限します。 管理アカウントでのワークロードの実行は避けることをお勧めします。管理アカウントは、メンバーアカウントに影響を及ぼすセキュリティガードレールを統制およびデプロイするために使用する必要があります。一部の AWS サービスでは、委任された管理者アカウントの使用がサポートされています。この委任アカウントを使用できる場合は、管理アカウントの代わりに使用する必要があります。組織の管理者アカウントへのアクセスは、厳しく制限する必要があります。 マルチアカウント戦略を用いると、ワークロードにガードレールを適用する際の柔軟性が大幅に向上します。AWS Security Reference Architecture では、アカウント構造の設計方法に関する規範ガイダンスが提供されます。AWS Control Tower などの AWS サービスは、組織全体で予防的コントロールと発見的コントロールの両方を一元管理する機能を提供します。組織内の各アカウントまたは OU の明確な目的を定義し、その目的に沿ってコントロールを制限します。 ## リソース **関連するドキュメント:** + [AWS Organizations](https://aws.amazon.com/organizations/) + [サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) + [Get more out of service control policies in a multi-account environment (マルチアカウント環境でサービスコントロールポリシーをさらに活用する)](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) + [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) **関連動画:** + [Enforce Preventive Guardrails using Service Control Policies (サービスコントロールポリシーを使用して予防的ガードレールを適用する)](https://www.youtube.com/watch?v=mEO05mmbSms) + [Building governance at scale with AWS Control Tower (AWS Control Tower を使用したガバナンスの大規模な構築)](https://www.youtube.com/watch?v=Zxrs6YXMidk) + [AWS Identity and Access Management deep dive (AWS Identity and Access Management の深堀り)](https://www.youtube.com/watch?v=YMj33ToS8cI) # SEC03-BP06 ライフサイクルに基づいてアクセスを管理する アクセスコントロールをオペレーター、アプリケーションのライフサイクル、一元化されたフェデレーションプロバイダーと統合します。たとえば、ユーザーが組織を離れるとき、またはロールを変更するときに、ユーザーのアクセス権を削除します。 複数のアカウントでワークロードを管理する場合、それらのアカウント間でリソースを共有するケースがあります。リソースの共有には、 [AWS Resource Access Manager (AWS RAM) を使用することをお勧めします](http://aws.amazon.com/ram/).このサービスを使用すると、AWS Organizations 組織および組織単位内で AWS リソースを簡単かつ安全に共有できます。AWS RAM を使用すると、共有されている組織または組織単位内外へのアカウントの移動に伴い、共有リソースへのアクセスの許可または取り消しが自動的に行われます。これで、意図したアカウントのみとのリソースの共有を確実に行えます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス ユーザーアクセスのライフサイクル: 新しいユーザーの参加、職務の変更、退職するユーザーに対するユーザーアクセスライフサイクルポリシーを実装して、現在のユーザーのみがアクセスできるようにします。 ## リソース **関連するドキュメント:** + [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [最小権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) + [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) + [必要でない認証情報を削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) + [「IAM ポリシーを管理する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) **関連動画:** + [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU) + [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70) # SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析 パブリックおよびクロスアカウントアクセスに焦点を当てた結果を継続的にモニタリングします。パブリックアクセスとクロスアカウントアクセスを減らして、このタイプのアクセスを必要とするリソースのみへのアクセスに限定します。 **一般的なアンチパターン:** + クロスアカウントのアクセスとリソースへのパブリックアクセスを統制するためのプロセスを遵守しない。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス AWS では、別のアカウントにあるリソースへのアクセス権を許可できます。直接的なクロスアカウントアクセスを許可するには、リソース ([Amazon Simple Storage Service (Amazon S3) バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)など) にアタッチされたポリシーを使用するか、アイデンティティが別のアカウントの IAM ロールを引き受けることを許可します。リソースポリシーを使用するときは、組織内のアイデンティティにアクセスが許可されており、リソースをパブリックアクセス可能にする意図があることを確認します。パブリックアクセス可能にする必要があるすべてのリソースを承認するプロセスを定義します。 [IAM Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) は [証明可能セキュリティ](https://aws.amazon.com/security/provable-security/) を使用して、アカウントの外部からリソースへのすべてのアクセスパスを識別します。また、リソースポリシーの継続的な確認と、パブリックおよびクロスアカウントアクセスの結果の報告により、広範囲なアクセス権の分析をしやすくします。すべてのアカウントについて表示できることを確認するために、AWS Organizations で IAM Access Analyzer を設定することを検討します。IAM Access Analyzer では、 [リソースのアクセス許可をデプロイする前に Access Analyzer の調査結果を](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)プレビューすることもできます。これにより、ポリシー変更によって、意図されたパブリックアクセスおよびクロスアカウントアクセスのみがリソースに付与されていることを検証できます。マルチアカウントアクセスについて設計するときは、 [ロールを引き受け可能なケースを制御するために信頼ポリシーを使用できます](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)。例えば、ロールの引き受けを特定の送信元 IP 範囲に限定できます。 また、 [AWS Config を使用して、](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) AWS Config ポリシーチェックで、リソースに意図しないパブリックアクセス設定があればレポートを生成し、修復することができます。例えば、 [AWS Control Tower](https://aws.amazon.com/controltower) および [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) などのサービスでは、AWS Organizations 全体でチェックとガードレールのデプロイが簡素化され、パブリックにアクセスできるリソースを特定および修復できます。例えば、AWS Control Tower にはマネージド型のガードレールが含まれており、 [Amazon EBS スナップショットがすべての AWS アカウントで復元可能かどうかを検出できます](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)。 ## リソース **関連するドキュメント:** + [AWS Identity and Access Management Access Analyzer を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected) + [AWS Control Tower のガードレール](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) + [AWS Foundational Security Best Practices 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) + [AWS Config マネージドルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) + [AWS Trusted Advisor チェックリファレンス](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) **関連動画:** + [Best Practices for securing your multi-account environment (マルチアカウント環境を守るためのベストプラクティス)](https://www.youtube.com/watch?v=ip5sn3z5FNg) + [Dive Deep into IAM Access Analyzer (IAM Access Analyzer を深堀りする)](https://www.youtube.com/watch?v=i5apYXya2m0) # SEC03-BP08 リソースを安全に共有する アカウント間または AWS Organizations 内の共有リソースの消費を管理します。共有リソースをモニタリングし、共有リソースへのアクセスを確認します。 **一般的なアンチパターン:** + 第三者にクロスアカウントアクセスを許可する際に、デフォルトの IAM 信頼ポリシーを使用する **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス 複数の AWS アカウントを使用してワークロードを管理するとき、アカウント間でのリソースの共有が必要になる場合があります。多くの場合、これは AWS Organizations 内でのクロスアカウント共有です。AWS の複数のサービス ( [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html)、[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html)、 [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html) など) には Organizations と統合されたクロスアカウント機能があります。そのため、 [AWS Resource Access Manager](https://aws.amazon.com/ram/) を使用して、その他の一般的なリソースを共有します。例えば、 [VPC サブネットや Transit Gateway アタッチメント](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall)、 [Amazon SageMaker Runtime パイプライン](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)などです。アカウントで Organizations 内のリソースのみを共有する場合は、 [サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) を使用して外部プリンシパルへのアクセスを禁止することをお勧めします。 リソースを共有するとき、意図しないアクセスから保護するための手段を講じる必要があります。アイデンティティベースのコントロールとネットワークコントロールを組み合わせて [組織のデータ境界を作成することをお勧めします](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)。これらのコントロールは、どのリソースが共有可能かを厳格に制限し、共有や公開が許可されるべきでないリソースについてはそれを禁止する必要があります。例えば、データ境界の一部として、VPC エンドポイントポリシーと `aws:PrincipalOrgId` 条件を使用すると、組織に属しているアイデンティティのみが Amazon S3 バケットにアクセスするように設定できます。 場合により、Organizations 外部でリソース共有を許可したり、アカウントへのアクセス権を第三者に付与したりする必要があるかもしれません。例えば、パートナーが提供する監視ソリューションが、貴社のアカウント内のリソースにアクセスする必要があるかもしれません。そのような場合、第三者にとって必要な権限のみを含む IAM クロスアカウントロールを作成する必要があります。また、外部 ID 条件を使用して信頼ポリシーを作成する [必要もあります](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)。外部 ID を使用する際は、第三者それぞれに固有の ID を生成する必要があります。固有の ID は第三者によって提供、制御されるべきではありません。第三者が貴社の環境にアクセスする必要がなくなった場合は、ロールを削除する必要があります。また、いずれの場合も、第三者に長期的な IAM 認証情報を提供することは避ける必要があります。共有をネイティブにサポートする他の AWS サービスを継続的に把握しておきます。例えば、AWS Well-Architected Tool [では、](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) 他の AWS アカウントとワークロードを共有できます。 Amazon S3 などのサービスを使用する際は、 [Amazon S3 バケットの ACL を無効にし、](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) IAM ポリシーを使用してアクセスコントロールを定義することをお勧めします。[Amazon S3 ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) オリジンが [Amazon CloudFront](https://aws.amazon.com/cloudfront/) からアクセスされることを制限するには、オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) に移行します。OAC では [AWS KMS を使用したサーバー側暗号化を含む追加機能がサポートされています。](https://aws.amazon.com/kms/)を使用します。 ## リソース **関連するドキュメント:** + [バケット所有者が所有権のないオブジェクトへのクロスアカウントアクセス許可を付与する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html) + [How to use Trust Policies with IAM (IAM ロールと信頼ポリシーを使用する方法)](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) + [Building Data Perimeter on AWS (AWS でのデータ境界の構築)](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) + [AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) **関連動画:** + [Granular Access with AWS Resource Access Manager (AWS Resource Access Manager を使用したきめ細かいアクセス)](https://www.youtube.com/watch?v=X3HskbPqR2s) + [Securing your data perimeter with VPC endpoints (VPC エンドポイントを使用したデータ境界の保護)](https://www.youtube.com/watch?v=iu0-o6hiPpI) + [ Establishing a data perimeter on AWS (AWS でのデータ境界の確立) ](https://www.youtube.com/watch?v=SMi5OBjp1fI) # 検知 **Topics** + [SEC 4 セキュリティイベントは、どのように検出して調査するのですか?](w2aac19b7b9b5.md) # SEC 4 セキュリティイベントは、どのように検出して調査するのですか? ログやメトリクスからイベントを可視化して把握し、分析します。セキュリティイベント、および潜在的な脅威に対する措置を講じて、ワークロードの保護に役立てます。 **Topics** + [SEC04-BP01 サービスとアプリケーションのログ記録を設定する](sec_detect_investigate_events_app_service_logging.md) + [SEC04-BP02 ログ、結果、メトリクスを一元的に分析する](sec_detect_investigate_events_analyze_all.md) + [SEC04-BP03 イベントへの応答を自動化する](sec_detect_investigate_events_auto_response.md) + [SEC04-BP04 実用的なセキュリティイベントを実装する](sec_detect_investigate_events_actionable_events.md) # SEC04-BP01 サービスとアプリケーションのログ記録を設定する アプリケーションログ、リソースログ、AWS のサービスログなど、ワークロード全体でログ記録を設定します。例えば、組織内のすべてのアカウントで AWS CloudTrail、Amazon CloudWatch Logs、Amazon GuardDuty および AWS Security Hub CSPM が有効になっていることを確認します。 基本的なプラクティスは、アカウントレベルで一連の検出メカニズムを確立することです。この基本的なメカニズムセットは、アカウント内のすべてのリソースに対する幅広いアクションを記録および検出することを目的としています。これらを使用すると、自動修復を含むオプションを備えた包括的な検出機能、および機能を追加するためのパートナー統合を構築できます。 AWS では、この基本セットを実装できるサービスには以下が含まれます。 + [AWS CloudTrail](http://aws.amazon.com/cloudtrail) では、AWS マネジメントコンソール、AWS SDK、コマンドラインツールなどの AWS のサービスを通じて実行されたアクションを含む、AWS アカウントアクティビティのイベント履歴を提供します。 + [AWS Config](http://aws.amazon.com/config) では、AWS リソース構成のモニタリングと記録が行われ、目標の構成に対する評価と修復が自動化できます。 + [Amazon GuardDuty](http://aws.amazon.com/guardduty) は脅威検出サービスです。悪意のある動作や不正な動作を継続的にモニタリングし、AWS のアカウントとワークロードを保護できるようにします。 + [AWS Security Hub CSPM](http://aws.amazon.com/security-hub) では、複数の AWS のサービスや任意のサードパーティー製品からのセキュリティアラートまたは検出結果の集約、整理、優先順位付けが一元的に行われ、セキュリティアラートとコンプライアンスステータスを包括的に把握できます。 アカウントレベルの基盤上に構築されている多くの中心的なAWSのサービスである [Amazon Virtual Private Cloud Console (Amazon VPC)](http://aws.amazon.com/vpc)サービスレベルのログ記録機能を提供します。[Amazon VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) を使用すると、ネットワークインターフェイスを出入りする IP トラフィックに関する情報をキャプチャし、接続履歴に関する貴重なインサイトを得て、異常な動作に基づいた自動アクションをトリガーできます。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや AWS のサービスから生成されないアプリケーションベースのログ記録の場合、ログは を使用して保存、分析できます。 [Amazon CloudWatch Logs](http://aws.amazon.com/cloudwatch)。クラウド [エージェント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html) は、オペレーティングシステムと実行中のアプリケーションからログを収集し、自動的に保存します。ログがCloudWatch Logsで利用可能になったら、 [リアルタイムで処理したり](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)、 [(CloudWatch Logs Insights) を使用して分析したりできます](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)。 ログの収集や集約と同様に重要な機能が、複雑なアーキテクチャによって生成される大量のログとイベントデータから意味のある情報を抽出する機能です。詳細については、 *モニタリング* セクションにある [信頼性の柱に関するホワイトペーパーを参照してください](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html) 。CloudWatch Logs エージェントがキャプチャするログファイルにアプリケーションデータが誤って入ってきた場合や、クロスリージョンロギングがログ集約用に設定されていて、特定の種類の情報を国境を越えて送付することに関する法的な考慮事項がある場合など、ログ自体に機密とみなされるデータが含まれる可能性があります。 1 つのアプローチとして、ログの配信時にイベントでトリガーされる AWS Lambda 関数を使用して、Amazon Simple Storage Service (Amazon S3) バケットなどの中央ログ記録の場所に転送する前にログデータをフィルタリングおよび編集することがあります。未編集のログは、法律および法務チームが定める「妥当な時間」が経過するまでローカルバケットに保持できます。経過した時点で、Amazon S3 ライフサイクルルールが自動的にログを削除できます。S3 Object Lock を使用して、Amazon S3 でログの保護を強化できます。 [Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html)Write-Once-Read-Many (WORM) モデルを使用してオブジェクトを保存できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS のサービスのログ記録を有効にする: 要求事項を遵守するため AWS のサービスのログ記録を有効にします。ログ記録機能には次のようなものがあります: Amazon VPC Flow Logs、Elastic Load Balancing (ELB) ログ、Amazon S3 バケットログ、CloudFront アクセスログ、Amazon Route 53 クエリログ、および Amazon Relational Database Service (Amazon RDS) ログ。 + [AWS 回答: AWS ネイティブのセキュリティロギング機能 ](https://aws.amazon.com/answers/logging/aws-native-security-logging-capabilities/) + オペレーティングシステムとアプリケーションごとのログ機能を評価して有効にし、不審な動作を検出します。 + [ CloudWatch Logs の開始方法 ](http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html) + [ デベロッパー用ツールおよびログ分析 ](https://aws.amazon.com/marketplace/search/results?category=4988009011) + ログに適切なコントロールを適用する: ログには機密情報が含まれている場合があるため、承認されたユーザーにのみログへのアクセス権を与えるようにします。Amazon S3 バケットと CloudWatch Logs のロググループに対するアクセス権を制限することを検討します。 + [ Amazon CloudWatch のための認証とアクセスコントロール ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html) + [Amazon S3 のアイデンティティとアクセスの管理 ](https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html) + 設定 [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html): GuardDuty は脅威検出サービスです。悪意のある動作や不正な動作を継続的に探し、AWS アカウント とワークロードを保護できるようにします。GuardDuty を有効にし、ラボを使用して E メールの自動アラートを設定します。 + [CloudTrail でカスタマイズされた証跡を設定する](http://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html): 証跡を設定するとデフォルトの期間よりも長くログを保存し、後で分析できます。 + 実現 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html): AWS Config は、AWS アカウント アカウントの AWS リソースの設定を詳細に表示します。このビューには、リソース間の関係と設定の履歴が含まれるため、時間の経過とともに設定と関係がどのように変わるかを確認できます。 + 実現 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): Security Hub CSPM では、AWS のセキュリティ状態の包括的なビューが提供され、セキュリティ業界の標準とベストプラクティスへの準拠を確認するのに役立ちます。Security Hub CSPM を使用すると、AWS アカウント、サービス、およびサポートしているサードパーティーのパートナー製品全体からセキュリティデータを収集し、セキュリティの傾向を分析して、最も優先度の高いセキュリティ問題を特定できます。 ## リソース **関連するドキュメント:** + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [Amazon EventBridge ](https://aws.amazon.com/eventbridge) + [ 開始方法: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html) + [セキュリティパートナーのソリューション: ログ記録とモニタリング](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) **関連動画:** + [ リソースの設定とコンプライアンスを一元的にモニタリングする ](https://youtu.be/kErRv4YB_T4) + [Amazon GuardDuty および AWS Security Hub CSPM の調査結果の修復 ](https://youtu.be/nyh4imv8zuk) + [ クラウドにおける変更管理: Amazon GuardDuty および AWS Security Hub CSPM](https://youtu.be/vhYsm5gq9jE) **関連する例:** + [ ラボ: 発見的統制の自動デプロイ ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html) # SEC04-BP02 ログ、結果、メトリクスを一元的に分析する セキュリティ運用チームは、ログを収集し、検索ツールを使用することによって、不正なアクティビティや意図しない変更の可能性がある、潜在的に関心のあるイベントを発見します。ただし、収集されたデータを分析して手動で情報を処理するだけでは、複雑なアーキテクチャから流れる大量の情報に対応するには不十分です。分析とレポートだけでは、適切なリソースを割り当てて、イベントをタイミング良く実行する作業が容易になる訳ではありません。 熟練したセキュリティオペレーションチームを構築するには、セキュリティイベントと調査結果の流れを、チケットシステム、バグまたは問題システム、その他のセキュリティ情報とイベント管理 (SIEM) システムなどの、通知およびワークフローシステムに深く統合することをお勧めします。これにより、メールや静的レポートからワークフローが排除され、イベントや調査結果のルーティング、エスカレート、管理が可能になります。多くの組織はセキュリティアラートをチャットまたはコラボレーションや開発者の生産性プラットフォームに統合しています。自動化に着手している組織は、API 主導の、低レイテンシーのチケット発行システムによって、「何を最初に自動化するか」を計画する際にかなりの柔軟性が得られます。 このベストプラクティスは、ユーザーアクティビティやネットワークイベントを示すログメッセージから生成されたセキュリティイベントだけでなく、インフラストラクチャ自体で検出された変更から生成されたセキュリティイベントにも適用できます。変更による悪影響が小さく、AWS Identity and Access Management (IAM) と AWS Organizations の設定の組み合わせではその実行を阻止できないような状況では、変更を検出し、変更が適切かどうかを判断し、その情報を正しい修復ワークフローにルーティングする機能が、安全なアーキテクチャを維持、検証するうえで不可欠です。 Amazon GuardDuty と AWS Security Hub CSPM は、他の AWS のサービスでも利用できるログレコードの集約、重複排除、分析メカニズムを提供します。GuardDuty は、AWS CloudTrail 管理やデータイベント、VPC DNS ログ、および VPC Flow Logs などのソースからの情報を取込み、集計し、分析します。Security Hub CSPM は、GuardDuty、AWS Config、Amazon Inspector、Amazon Macie、AWS Firewall Manager、および AWS Marketplace で利用できるかなりの数のサードパーティーセキュリティ製品、そして適切にビルドした場合は独自のコードからの出力を取込み、集計、分析できます。GuardDuty と Security Hub CSPM のどちらにも、複数のアカウントにわたって調査結果とインサイトを集約できるマスターメンバーモデルがあります。Security Hub CSPM は、オンプレミスの SIEM を導入しているお客様に AWS 側のログ/アラートのプリプロセッサ/アグリゲータとしてよく使用され、お客様はそこから AWS Lambda ベースのプロセッサとフォワーダーを介して Amazon EventBridge を取り込むことができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + ログ処理機能を評価する: ログの処理に使用できるオプションを評価します。 + [Amazon OpenSearch Service を使用して (ほぼ) あらゆる対象をログ記録およびモニタリングする ](https://d1.awsstatic.com/whitepapers/whitepaper-use-amazon-elasticsearch-to-log-and-monitor-almost-everything.pdf) + [ログ記録および分析ソリューションを専門とするパートナーを探す ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring) + CloudTrail ログの分析の最初の作業として Amazon Athena をテストする + [ CloudTrail ログを分析するように Athena を設定する ](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html) + AWS での集中ロギングを実装する: 複数のソースからのログ記録を一元化する次の AWS のサンプルソリューションを参照してください。 + [集中ロギングソリューション ](https://aws.amazon.com/solutions/centralized-logging/https://aws.amazon.com/solutions/centralized-logging/) + パートナーで集中ロギングを実装する: APN パートナーは、ログを一元的に分析するためのソリューションを提供しています。 + [ ログ記録とモニタリング ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring) ## リソース **関連するドキュメント:** + [AWS の回答: 集中ログ記録 ](https://aws.amazon.com/answers/logging/centralized-logging/) + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [Amazon EventBridge ](https://aws.amazon.com/eventbridge) + [ 開始方法: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html) + [セキュリティパートナーのソリューション: ログ記録とモニタリング](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) **関連動画:** + [ リソースの設定とコンプライアンスを一元的にモニタリングする ](https://youtu.be/kErRv4YB_T4) + [Amazon GuardDuty および AWS Security Hub CSPM の調査結果の修復 ](https://youtu.be/nyh4imv8zuk) + [ クラウドにおける変更管理: Amazon GuardDuty および AWS Security Hub CSPM](https://youtu.be/vhYsm5gq9jE) # SEC04-BP03 イベントへの応答を自動化する 自動化を使用してイベントを調査および修正することで、人為的な労力やエラーが軽減され、調査機能をスケールできます。定期的なレビューは、自動化ツールを調整するのに役立ちます。継続して繰り返し行います。 AWS では、Amazon EventBridge を使用して、関心のあるイベントと予期しない変更についての情報の調査を自動化されたワークフローに組み込むことができます。このサービスには、スケーラブルなルールエンジンが備わっており、ネイティブの AWS イベント形式 (AWS CloudTrail イベントなど)と、独自のアプリケーションから生成できるカスタムイベントの両方を仲介できます。Amazon GuardDuty では、インシデントレスポンスシステムを構築するワークフローシステム (AWS Step Functions) や、中央のセキュリティアカウントにイベントをルーティングできます。また、バケットにルーティングして詳細分析を実行することもできます。 変更を検出してこの情報を正しいワークフローにルーティングするには、AWS Config ルール と [コンフォーマンスパックを使用できます。](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)AWS Config は、(EventBridge より高いレイテンシーを通して) スコープ内サービスへの変更を検出し、AWS Config ルール ルールを使用して分析できるイベントを生成します。分析されたイベントは、ロールバックやコンプライアンスポリシーの適用のほか、変更管理プラットフォームや運用チケット発行システムなどのシステムに対する情報の転送に使用できます。AWS Config イベントに対応する独自の Lambda 関数を作成するだけでなく、 [AWS Config ルール 開発キット](https://github.com/awslabs/aws-config-rdk)および [オープンソースライブラリの](https://github.com/awslabs/aws-config-rules) AWS Config ルール も利用できます。コンフォーマンスパックとは、YAML テンプレートとして作成される単一エンティティとしてデプロイする一連の AWS Config ルール および修正アクションです。A [サンプルコンフォーマンスパックテンプレートは](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) Well-Architected セキュリティの柱で利用できます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + GuardDuty で自動アラートを実装する: GuardDuty は、脅威検出サービスです。悪意のあるアクティビティや不正な動作を継続的にモニタリングし、AWS アカウント とワークロードを保護します。GuardDuty を有効にし、自動アラートを設定します。 + 調査プロセスを自動化する: 時間を節約するため、イベントを調査して情報を管理者に報告する自動化されたプロセスを開発します。 + [ ラボ: Amazon GuardDuty ハンズオン ](https://hands-on-guardduty.awssecworkshops.com/) ## リソース **関連するドキュメント:** + [AWS の回答: 集中ログ記録 ](https://aws.amazon.com/answers/logging/centralized-logging/) + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [Amazon EventBridge ](https://aws.amazon.com/eventbridge) + [ 開始方法: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html) + [セキュリティパートナーのソリューション: ログ記録とモニタリング](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) + [ Amazon GuardDuty の設定 ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) **関連動画:** + [ リソースの設定とコンプライアンスを一元的にモニタリングする ](https://youtu.be/kErRv4YB_T4) + [Amazon GuardDuty および AWS Security Hub CSPM の調査結果の修復 ](https://youtu.be/nyh4imv8zuk) + [ クラウドにおける変更管理: Amazon GuardDuty および AWS Security Hub CSPM](https://youtu.be/vhYsm5gq9jE) **関連する例:** + [ラボ: 発見的統制の自動デプロイ ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html) # SEC04-BP04 実用的なセキュリティイベントを実装する チームに送信され、チームによるアクションが可能なアラートを作成します。チームがアクションを実行するための関連情報がアラートに含まれていることを確認します。使用する検知メカニズムごとに、 [ランブック](https://wa.aws.amazon.com/wat.concept.runbook.en.html) または [プレイブック形式の](https://wa.aws.amazon.com/wat.concept.playbook.en.html)調査プロセスも用意する必要があります。例えば、 [Amazon GuardDuty](http://aws.amazon.com/guardduty)を有効にすると、 [さまざまな調査結果が生成されます。](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html)。調査結果タイプごとにランブックエントリが必要です。例えば、 [トロイの木馬](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_trojan.html) が検出された場合、調査して修復するよう指示する簡単な説明をランブックに記載する必要があります。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + AWS のサービスで利用可能なメトリクスを検出する: Amazon CloudWatch で利用可能な、利用中のサービスのメトリクスを確認することができます。 + [AWS のサービスドキュメント](https://aws.amazon.com/documentation/) + [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + Amazon CloudWatch アラームを設定します。 + [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ## リソース **関連するドキュメント:** + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [Amazon EventBridge ](https://aws.amazon.com/eventbridge) + [Security Partner Solutions: Logging and Monitoring (セキュリティパートナーのソリューション: ログ記録とモニタリング)](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) **関連動画:** + [ Centrally Monitoring Resource Configuration and Compliance (リソースの設定とコンプライアンスを一元的にモニタリングする) ](https://youtu.be/kErRv4YB_T4) + [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Amazon GuardDuty および AWS Security Hub CSPM の調査結果の修復) ](https://youtu.be/nyh4imv8zuk) + [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (クラウドにおける変更管理: Amazon GuardDuty および AWS Security Hub CSPM) ](https://youtu.be/vhYsm5gq9jE) # インフラストラクチャ保護 **Topics** + [SEC 5 ネットワークリソースをどのように保護しますか?](w2aac19b7c11b5.md) + [SEC 6 どのようにコンピューティングリソースを保護するのですか?](w2aac19b7c11b7.md) # SEC 5 ネットワークリソースをどのように保護しますか? 何らかの形式のネットワーク接続があるワークロードは、インターネットでもプライベートネットワークでも、外部および内部ネットワークベースの脅威から保護するために、複数の防御レイヤーが必要です。 **Topics** + [SEC05-BP01 ネットワークレイヤーを作成する](sec_network_protection_create_layers.md) + [SEC05-BP02 すべてのレイヤーでトラフィックを制御する](sec_network_protection_layered.md) + [SEC05-BP03 ネットワーク保護を自動化する](sec_network_protection_auto_protect.md) + [SEC05-BP04 検査と保護を実装する](sec_network_protection_inspection.md) # SEC05-BP01 ネットワークレイヤーを作成する 到達可能性要件をレイヤーに共有するコンポーネントをグループ化します。例えば、インターネットアクセスを必要としない仮想プライベートクラウド (VPC) 内のデータベースクラスターは、インターネットへのルート、またはインターネットからのルートがないサブネットに配置する必要があります。VPC を使用せずに稼働するサーバーレスワークロードでは、マイクロサービスを使用した同様の階層化とセグメント化でも同じ目標を達成できます。 共通の達成可能要件を持つ Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Relational Database Service (Amazon RDS) データベースクラスター、AWS Lambda 関数などのコンポーネントは、サブネットで形成されるレイヤーにセグメント化できます。例えば、インターネットアクセスを必要としない VPC 内の Amazon RDS データベースクラスターは、インターネットへのルート、またはインターネットからのルートがないサブネットに配置する必要があります。このコントロールに対する階層的なアプローチは、意図しないアクセスを許可する可能性がある単一レイヤーの誤設定の影響を軽減します。Lambda の場合は、VPC 内で関数を実行して、VPC ベースのコントロールを利用できます。 数千の VPC、AWS アカウント、オンプレミスネットワークを含むネットワーク接続の場合は、AWS Transit Gateway を使用する必要があります。 [AWS Transit Gateway](http://aws.amazon.com/transit-gateway).AWS Transit Gateway は、スポークのように機能するすべての接続されたネットワーク間でトラフィックがどのようにルーティングされるかを制御するハブとして機能します。Amazon Virtual Private Cloud と AWS Transit Gateway の間のトラフィックは、AWS プライベートネットワーク上にとどまります。これにより、分散型サービス妨害 (DDoS) 攻撃や一般的な脆弱性攻撃 (SQL インジェクション、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、破損した認証コードの不正使用など) といった外部からの脅威ベクトルが軽減されます。AWS Transit Gateway のリージョン間ピアリングはまた、リージョン間トラフィックを単一障害点や帯域幅のボトルネックなしで暗号化します。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + VPC にサブネットを作成する: (複数のアベイラビリティーゾーンを含むグループで) 各レイヤーのサブネットを作成し、ルートテーブルを関連付けてルーティングを制御します。 + [VPC とサブネット ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) + [ルートテーブル ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) ## リソース **関連するドキュメント:** + [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) + [ Amazon Inspector ](https://aws.amazon.com/inspector) + [Amazon VPC セキュリティ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) + [AWS WAF の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) **関連動画:** + [多くの VPC 用の AWS Transit Gateway リファレンスアーキテクチャ ](https://youtu.be/9Nikqn_02Oc) + [Amazon CloudFront、AWS WAF、AWS Shield によるアプリケーションの高速化と保護](https://youtu.be/0xlwLEccRe0) **関連する例:** + [ラボ: VPC の自動デプロイ](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) # SEC05-BP02 すべてのレイヤーでトラフィックを制御する  ネットワークトポロジを設計する際には、各コンポーネントの接続要件を調べる必要があります。たとえば、コンポーネントがインターネットアクセス (インバウンドおよびアウトバウンド) や、VPC、エッジサービス、外部データセンターへの接続を必要とする場合です。 VPC では、設定したプライベート IPv4 アドレス範囲または AWS によって選択された IPv6 アドレス範囲を使用して、AWS リージョン にまたがるネットワークトポロジを定義できます。インバウンドトラフィックとアウトバウンドトラフィックの両方に、多層防御アプローチを用いた複数のコントロールを適用する必要があります。これには、セキュリティグループ (ステートフルインスペクションファイアウォール)、ネットワーク ACL、サブネット、ルートテーブルの使用などが含まれます。VPC 内では、アベイラビリティーゾーンにサブネットを作成できます。各サブネットには、トラフィックがサブネット内でたどるパスを管理するためのルーティングルールを定義するルートテーブルを関連付けることができます。インターネットまたは VPC にアタッチされた NAT あるいは他の VPC ゲートウェイを経由するルートを設定することで、インターネットルーティングが可能なサブネットを定義できます。 インスタンス、Amazon Relational Database Service (Amazon RDS) データベース、またはその他のサービスが VPC 内で起動されると、ネットワークインターフェイスごとに独自のセキュリティグループが設定されます。このファイアウォールはオペレーティングシステムレイヤーの外側にあり、許可されるインバウンドトラフィックとアウトバウンドトラフィックのルールを定義するために使用できます。また、セキュリティグループ間の関係も定義できます。たとえば、データベース層のセキュリティグループ内のインスタンスは、関連するインスタンスに適用されるセキュリティグループを参照して、アプリケーション層のインスタンスからのトラフィックのみを受け入れます。TCP 以外のプロトコルを使用している場合を除き、ロードバランサーや [CloudFront](https://aws.amazon.com/cloudfront) なしでインターネットから Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに直接アクセスできるようにする必要はありません (セキュリティグループによって制限されているポートでも)。 これにより、オペレーティングシステムやアプリケーションの問題による意図しないアクセスから保護できます。サブネットには、ステートレスファイアウォールとして機能する、サブネットにアタッチされたネットワーク ACL を設定することもできます。レイヤー間で許可されるトラフィックの範囲を絞り込むようにネットワーク ACL を設定する必要があります。インバウンドルールとアウトバウンドルールの両方を定義する必要があることに注意してください。 一部の AWS サービスは、インターネットにアクセスして API 呼び出しをする [(AWS API エンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html) がある) ためのコンポーネントが必要です。その他の AWS サービスは [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html) を Amazon VPC 内で使用します。Amazon S3 や Amazon DynamoDB を含む多くの AWS サービスは VPC エンドポイントをサポートしており、このテクノロジーは次で一般化されています。 [AWS PrivateLink](https://aws.amazon.com/privatelink/).AWS のサービス、サードパーティーのサービス、および他の VPC セキュリティでホストされる独自のサービスにアクセスするには、このアプローチを使用することが推奨されます。AWS PrivateLink のすべてのネットワークトラフィックは、グローバルな AWS バックボーンにとどまり、インターネットにトラバースすることはありません。接続を開始できるのは、サービスのプロバイダーではなくサービスのコンシューマーのみです。外部サービスアクセスに AWS PrivateLink を使用することにより、インターネットなしでエアギャップ VPC を作成することができるため、外部の脅威ベクトルから VPC を保護するのに役立ちます。サードパーティーのサービスは AWS PrivateLink を使用して、プライベート PI アドレス経由で顧客が VPC からサービスに接続できるようにします。インターネットへのアウトバウンド接続を必要とする VPC アセットでは、これらは、AWS が管理する NAT ゲートウェイ、アウトバウンド専用のインターネットゲートウェイ、ユーザーが作成して管理するウェブプロキシを経由するアウトバウンド (一方向) でのみ可能です。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + VPC 内のネットワークトラフィックを制御する: VPC ベストプラクティスを実装してトラフィックを制御する + [Amazon VPC セキュリティ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) + [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) + [Amazon VPC セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) + [ネットワーク ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) + エッジでのトラフィックを制御する: Amazon CloudFront などのエッジサービスを実装して、追加の保護レイヤーやその他の機能を提供します。 + [Amazon CloudFront ユースケース](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/IntroductionUseCases.html) + [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + [AWS Web Application Firewall (AWS WAF)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-section.html) + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + [Amazon VPC Ingress Routing](https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-vpc-ingress-routing-insert-virtual-appliances-forwarding-path-vpc-traffic/) + プライベートネットワークトラフィックを制御する: ワークロードのプライベートトラフィックを保護するサービスを実装します。 + [Amazon VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) + [Amazon VPC エンドポイントサービス (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) + [Amazon VPC トランジットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) + [AWS サイト間 VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) + [AWS クライアント VPN ](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/user-getting-started.html) + [Amazon S3 Access Points](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-points.html) ## リソース **関連するドキュメント:** + [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) + [Amazon Inspector](https://aws.amazon.com/inspector) + [AWS WAF の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) **関連動画:** + [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) + [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, andAWS Shield](https://youtu.be/0xlwLEccRe0) **関連する例:** + [Lab: Automated Deployment of VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) # SEC05-BP03 ネットワーク保護を自動化する 保護メカニズムを自動化し、脅威インテリジェンスと異常検出に基づく自己防御型ネットワークを提供します。たとえば、現在の脅威に適応し、その影響を軽減できる侵入検知および防止ツールなどです。ウェブアプリケーションファイアウォールは、ネットワーク保護を自動化できる例の 1 つです。たとえば、AWS WAF セキュリティの自動化ソリューション ([https://github.com/awslabs/aws-waf-security-automations](https://github.com/awslabs/aws-waf-security-automations)を使用して、既知の脅威アクターに関連付けられた IP アドレスからのリクエストを自動的にブロックします。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス + ウェブベースのトラフィックの保護を自動化する: AWS では、AWS CloudFormation を使用して、一般的なウェブベースの攻撃をフィルタリングするために設計された AWS WAF ルールセットを自動的にデプロイするソリューションを提供しています。ユーザーは、AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) に含まれるルールを定義する、あらかじめ設定された保護機能から選択することができます。 + [AWS WAF のセキュリティオートメーション](https://aws.amazon.com/solutions/aws-waf-security-automations/) + AWS Partner ソリューションを検討する: AWS パートナーは、お客様のオンプレミス環境にある既存のコントロールと同等または統合された、業界をリードする何百もの製品を提供しています。これらの製品は、既存の AWS サービスを補完し、包括的なセキュリティアーキテクチャの導入と、クラウドとオンプレミス環境におけるよりシームレスなエクスペリエンスを実現します。 + [インフラストラクチャのセキュリティ](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) ## リソース **関連するドキュメント:** + [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) + [Amazon Inspector](https://aws.amazon.com/inspector) + [Amazon VPC のセキュリティ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) + [AWS WAF の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) **関連動画:** + [AWS Transit Gateway reference architectures for many VPCs (多くの VPC 用の AWS Transit Gateway リファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc) + [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Amazon CloudFront、AWS WAF、AWS Shield によるアプリケーションの高速化と保護) ](https://youtu.be/0xlwLEccRe0) **関連する例:** + [ラボ: VPC の自動デプロイ](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) # SEC05-BP04 検査と保護を実装する 各レイヤーでトラフィックを検査し、フィルタリングします。VPC の設定に潜在的な意図しないアクセスの可能性がないかを検査するには、 [VPC Network Access Analyzer を使用できます。](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html).ネットワークアクセス要件を指定して、それを満たさない潜在的なネットワークパスを特定できます。HTTP ベースのプロトコルを介してトランザクションを実行するコンポーネントの場合、一般的な攻撃からの保護にはウェブアプリケーションファイアウォールが役立ちます。 [AWS WAF](https://aws.amazon.com/waf) は、Amazon API Gateway API、Amazon CloudFront、または Application Load Balancer に転送される設定可能なルールに一致する HTTP リクエストを監視してブロックできるウェブアプリケーションファイアウォールです。AWS WAF の使用を開始するには 、 [AWS マネージドルール](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) を独自のルールと組み合わせて使用するか、既存の [パートナー統合を使用できます。](https://aws.amazon.com/waf/partners/)。 AWS Organizations 全体にわたって AWS WAF、AWS Shield Advanced による保護、Amazon VPC セキュリティグループを管理するには、AWS Firewall Manager を使用できます。AWS Firewall Manager を使用すると、アカウントとアプリケーション全体にわたってファイアウォールルールを一元的に設定および管理できるため、一般的なルールの適用を簡単に拡張できます。また、 [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-responding.html)、または  [ソリューション](https://aws.amazon.com/solutions/aws-waf-security-automations/) を使用して、攻撃に迅速に対応できます。これらは、ウェブアプリケーションへの不要なリクエストを自動的にブロックします。Firewall Manager は、 [AWS ネットワークファイアウォールとも併用できます。](https://aws.amazon.com/network-firewall/).AWS ネットワークファイアウォールは、ルールエンジンを使用して、ステートフルとステートレスの両方のネットワークトラフィックを細かくコントロールするマネージドサービスです。ルールに対しては [Suricata 対応の](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) オープンソース侵入防止システム (IPS) 仕様がサポートされており、ワークロードの保護に役立ちます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + Amazon GuardDuty を設定する: GuardDuty は、脅威検出サービスです。悪意のあるアクティビティや不正な動作を継続的にモニタリングし、AWS アカウント とワークロードを保護します。GuardDuty を有効にし、自動アラートを設定します。 + [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) + [ラボ: 発見的統制の自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html) + 仮想プライベートクラウド (VPC) フローログを設定する: VPC フローログは、VPC のネットワークインターフェイス間を行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。フローログデータは Amazon CloudWatch Logs および Amazon Simple Storage Service (Amazon S3) にパブリッシュできます。フローログを作成した後、選択した送信先でデータを取得したり表示したりできます。 + VPC トラフィックのミラーリングを検討する: トラフィックミラーリングは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの Elastic Network Interface からネットワークトラフィックをコピーし、コンテンツ検査、脅威のモニタリング、トラブルシューティングのために帯域外セキュリティおよびモニタリングアプライアンスに送信するために使用できる Amazon VPC の機能です。 + [VPC トラフィックミラーリング](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) ## リソース **関連するドキュメント:** + [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) + [Amazon Inspector](https://aws.amazon.com/inspector) + [Amazon VPC セキュリティ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) + [AWS WAF の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) **関連動画:** + [AWS Transit Gateway reference architectures for many VPCs (多くの VPC 用の AWS Transit Gateway リファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc) + [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield (Amazon CloudFront、AWS WAF、AWS Shield によるアプリケーションの高速化と保護)](https://youtu.be/0xlwLEccRe0) **関連する例:** + [ラボ: VPC の自動デプロイ](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) # SEC 6 どのようにコンピューティングリソースを保護するのですか? ワークロード内のコンピューティングリソースを内外の脅威から守るには、複数の防御レイヤーを設ける必要があります。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。 **Topics** + [SEC06-BP01 脆弱性管理を実行する](sec_protect_compute_vulnerability_management.md) + [SEC06-BP02 攻撃対象領域を縮小する](sec_protect_compute_reduce_surface.md) + [SEC06-BP03 マネージドサービスを活用する](sec_protect_compute_implement_managed_services.md) + [SEC06-BP04 コンピューティング保護を自動化する](sec_protect_compute_auto_protection.md) + [SEC06-BP05 ユーザーがリモートからアクションを実行できるようにする](sec_protect_compute_actions_distance.md) + [SEC06-BP06 ソフトウェアの整合性を検証する](sec_protect_compute_validate_software_integrity.md) # SEC06-BP01 脆弱性管理を実行する コード、依存関係、インフラストラクチャ内の脆弱性のスキャンとパッチ適用を頻繁に実施し、新しい脅威から保護します。 コンピューティングインフラストラクチャの設定から始め、AWS CloudFormation を使用してリソースの作成と更新を自動化できます。CloudFormation を使うと、AWS の例を使用するか、または自分で記述することにより、YAML または JSON で書かれたテンプレートを作成できます。これにより、 [CloudFormation Guard](https://aws.amazon.com/about-aws/whats-new/2020/10/aws-cloudformation-guard-an-open-source-cli-for-infrastructure-compliance-is-now-generally-available/)で検証できるデフォルトで保護されたインフラストラクチャを作成できるため、時間を節約して設定エラーのリスクを低減できます。インフラストラクチャをビルドして、 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)などの継続的デリバリーを使ってアプリケーションをデプロイすることで、ビルド、テスト、およびリリースを自動化できます。 Amazon Elastic Compute Cloud(Amazon EC2) インスタンス、Amazon マシンイメージ (AMI)、およびその他多くのコンピューティングリソースなど、AWS リソースのパッチ管理を行う責任があります。Amazon EC2 インスタンスの場合、AWS Systems Manager Patch Manager は、セキュリティ関連および他のタイプの更新の両方を使用して、マネージドインスタンスにパッチを適用するプロセスを自動化します。Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用できます。(Windows サーバーでは、アプリケーションサポートは Microsoft アプリケーションの更新に限定されます)。 Patch Manager を使用して、Service Packs on Windows インスタンスをインストールし、Linux インスタンスのマイナーバージョンアップグレードを実行します。オペレーティングシステムのタイプ別に、Amazon EC2 インスタンス、オンプレミスのサーバー、仮想マシン (VM) のフリートにパッチを適用できます。これには、Windows Server、Amazon Linux、Amazon Linux 2、CentOS、Debian Server、Oracle Linux、Red Hat Enterprise Linux (RHEL)、SUSE Linux Enterprise Server (SLES)、および Ubuntu Server に対応するバージョンが含まれます。インスタンスをスキャンして、不足しているパッチのレポートのみを表示したり、不足しているすべてのパッチをスキャンして自動的にインストールしたりできます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + Amazon Inspector を設定する: Amazon Inspector は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのネットワークアクセシビリティと、それらのインスタンスで実行されるアプリケーションの状態をテストします。Amazon Inspector は、アプリケーションの露出、脆弱性、ベストプラクティスからの逸脱を評価します。 + [Amazon Inspector とは何ですか?](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) + ソースコードをスキャンする: ライブラリや依存関係をスキャンして脆弱性に対応します。 + [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) + [OWASP: Source Code Analysis Tools](https://owasp.org/www-community/Source_Code_Analysis_Tools) ## リソース **関連するドキュメント:** + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [Replacing a Bastion Host with Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) + [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) **関連動画:** + [Running high-security workloads on Amazon EKS](https://youtu.be/OWRWDXszR-4) + [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) + [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) **関連する例:** + [Lab: Automated Deployment of Web Application Firewall](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) # SEC06-BP02 攻撃対象領域を縮小する オペレーティングシステムを強化し、使用するコンポーネント、ライブラリ、外部から利用可能なサービスを最小限に抑えることで、意図しないアクセスへの露出を減らします。まずオペレーティングシステムパッケージやアプリケーション (Amazon Elastic Compute Cloud (Amazon EC2) ベースのワークロード)、あるいはコード内の外部ソフトウェアモジュールなどの、未使用のコンポーネント (すべてのワークロード) を減らします。一般的なオペレーティングシステムやサーバーソフトウェア向けの強化およびセキュリティ設定ガイドが多数あります。例えば、 [Center for Internet Security](https://www.cisecurity.org/) から始めて、反復できます。 Amazon EC2 では、パッチしたり強化したりした自身の Amazon マシンイメージ (AMI) を作成して、組織の具体的なセキュリティ要件を満たすのに役立てることができます。AMI に適用するパッチやその他のセキュリティコントロールは、作成された時点では効果的です。起動後、例えば AWS Systems Manager で変更しない限り動的ではありません。 EC2 Image Builder を使って、安全な AMI をビルドするプロセスを簡素化できます。EC2 Image Builder は、自動化を記述して維持せずにゴールデンイメージを作成して維持するための作業を大幅に軽減します。ソフトウェアアップデートが利用可能になると、ユーザーがイメージビルドを手動で開始しなくても、新しいイメージが自動作成されます。EC2 Image Builder では、AWS 提供のテストと自分のテストの本番で使用する前に、イメージの機能とセキュリティを簡単に検証できます。また AWS 提供のセキュリティ設定を適用して、イメージをさらにセキュリティ保護し、内部セキュリティ条件を満たすことができます。例えば、AWS を使って、セキュリティテクニカル実装ガイド (STIG) に準拠するイメージを作成できます。 サードパーティー製の静的コード分析ツールを使用して、チェックされていない関数入力境界や、該当する共有脆弱性および露出 (CVE) などの一般的なセキュリティ問題を特定できます。専用のインフラストラクチャで [Amazon CodeGuru](https://aws.amazon.com/codeguru/) を、サポートされる言語に対して使用できます。コードがリンクしているライブラリが最新バージョンであるかどうか、ライブラリ自体に CVE が含まれていないかどうか、ライブラリにソフトウェアポリシー要件を満たすライセンス条件があるかどうかを判断するために依存関係チェックツールを使用することもできます。 Amazon Inspectorを使用すると、インスタンスに対する設定評価を実行して既知の CVE を確認したり、セキュリティベンチマークに対して評価したり、欠陥の通知を自動化したりすることができます。Amazon Inspector は本番環境インスタンス上またはビルドパイプライン上で実行され、調査結果があるとデベロッパーとエンジニアに通知します。調査結果にはプログラムを使用してアクセスし、バックログやバグ追跡システムにチームを誘導することができます。 [EC2 Image Builder](https://aws.amazon.com/image-builder/) は、自動パッチ適用、AWS が提供するセキュリティポリシーの適用、その他のカスタマイズにより、サーバーイメージ (AMI) を保持するために使用できます。コンテナを使用する場合は、ビルドパイプラインの [ECR イメージスキャン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) をイメージリポジトリに対して定期的に実行し、コンテナ内の CVE を探します。 Amazon Inspector やその他のツールは、設定や CVE の有無を特定するのには効果的ですが、アプリケーションレベルでワークロードをテストするには他の方法が必要になります。 [ファジング](https://owasp.org/www-community/Fuzzing) は、オートメーションを使用して不正な形式のデータを入力フィールドやアプリケーションの他の領域に挿入するバグを見つけるためのよく知られた手法です。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + オペレーティングシステムを強化する: ベストプラクティスを満たすようにオペレーティングシステムを設定します。 + [Amazon Linux のセキュリティ保護](https://www.cisecurity.org/benchmark/amazon_linux/) + [Microsoft Windows Server のセキュリティ保護](https://www.cisecurity.org/benchmark/microsoft_windows_server/) + コンテナ化されたリソースを強化する: セキュリティのベストプラクティスを満たすよう、コンテナ化されたリソースを設定します。 + AWS Lambda のベストプラクティスを導入する + [AWS Lambda のベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) ## リソース **関連するドキュメント:** + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [要塞ホストを Amazon EC2 Systems Manager と置換する](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) + [AWS Lambda のセキュリティ概要](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) **関連動画:** + [Amazon EKS で高セキュリティワークロードを実行する](https://youtu.be/OWRWDXszR-4) + [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) + [Amazon EC2 インスタンスメタデータサービスのセキュリティに関するベストプラクティス](https://youtu.be/2B5bhZzayjI) **関連する例:** + [ラボ: ウェブアプリケーションファイアウォールの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) # SEC06-BP03 マネージドサービスを活用する Amazon Relational Database Service (Amazon RDS)、AWS Lambda、Amazon Elastic Container Service (Amazon ECS) などのリソースを管理するサービスを実装し、共有責任モデルの一部としてのセキュリティメンテナンスタスクを減らします。例えば、Amazon RDS は、リレーショナルデータベースのセットアップ、運用、スケーリングを支援し、ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなどの管理タスクを自動化します。つまり、「AWS Well-Architected フレームワーク」で説明されているその他の方法でアプリケーションを保護することに集中できる時間が増加します。Lambda では、サーバーのプロビジョニングや管理を行わずにコードを実行できるため、インフラストラクチャやオペレーティングシステムではなく、コードレベルの接続、呼び出し、セキュリティに集中するだけで済みます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 利用可能なサービスを調べる: Amazon RDS、AWS Lambda、Amazon ECS などのリソースを管理するサービスを調査、テスト、実装します。 ## リソース **関連するドキュメント:** + [AWS ウェブサイト ](https://aws.amazon.com/) + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [Replacing a Bastion Host with Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) + [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) **関連動画:** + [Running high-security workloads on Amazon EKS](https://youtu.be/OWRWDXszR-4) + [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) + [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) **関連する例:** + [Lab: AWS Certificate Manager Request Public Certificate ](https://wellarchitectedlabs.com/security/200_labs/200_certificate_manager_request_public_certificate/) # SEC06-BP04 コンピューティング保護を自動化する 脆弱性管理、攻撃対象領域削減、リソース管理などのコンピューティング保護メカニズムを自動化します。自動化により、ワークロードの他の側面の保護に時間を使えるようになり、人為的ミスを犯すリスクを軽減できます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 設定管理を自動化する: 設定管理サービスまたはツールを使用して、リモートでアクションを実行し、安全な設定を自動的に適用および検証します。 + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) + [ラボ: VPC の自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) + [ラボ: EC2 ウェブアプリケーションの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) + Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパッチを自動化する: インスタンスの場合、AWS Systems Manager Patch Manager は、セキュリティ関連および他のタイプの更新の両方を使用して、マネージドインスタンスにパッチを適用するプロセスを自動化します。Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用できます。 + [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) + [AWS Systems Manager オートメーションを使った一元化されたマルチアカウントおよびマルチリージョンパッチ適用](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) + 侵入検知と防止ツールを実装する: 侵入検知と防止ツールを実装することで、インスタンス上の悪意のあるアクティビティをモニタリングし、停止できます。 + AWS Partner ソリューションを検討する: AWS パートナーは、オンプレミス環境の既存のコントロールと同等、同一、またはそれらと統合される、業界をリードする多くの製品を提供しています。これらの製品は、AWS の既存のサービスを補完し、クラウド環境とオンプレミス環境にわたって包括的なセキュリティアーキテクチャと、よりシームレスなエクスペリエンスをデプロイできるようにします。 + [インフラストラクチャのセキュリティ](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) ## リソース **関連するドキュメント:** + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) + [AWS Systems Manager オートメーションを使った一元化されたマルチアカウントおよびマルチリージョンパッチ適用](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) + [インフラストラクチャのセキュリティ](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) + [要塞ホストを Amazon EC2 Systems Manager と置換する](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) + [AWS Lambda のセキュリティ概要](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) **関連動画:** + [Amazon EKS で高セキュリティワークロードを実行する](https://youtu.be/OWRWDXszR-4) + [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) + [Amazon EC2 インスタンスメタデータサービスのセキュリティに関するベストプラクティス](https://youtu.be/2B5bhZzayjI) **関連する例:** + [ラボ: ウェブアプリケーションファイアウォールの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) + [ラボ: EC2 ウェブアプリケーションの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) # SEC06-BP05 ユーザーがリモートからアクションを実行できるようにする インタラクティブアクセスの機能を排除すると、人為的ミスのリスクが軽減され、設定や管理が手動で行われる可能性が低くなります。たとえば、直接アクセスや踏み台ホスト経由のアクセスを許可する代わりに、infrastructure-as-codeを使って Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをデプロイし、次に AWS Systems Manager などのツールを使って Amazon EC2 を管理します。AWS Systems Manager は、 [オートメーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) [ワークフロー、](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)io1[ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) (プレイブック)、 [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)などの機能を使用して、さまざまなメンテナンスおよびデプロイタスクを自動化できます。AWS CloudFormation スタックは、パイプラインから構築され、AWS マネジメントコンソール や API を直接使用することなく、インフラストラクチャのデプロイおよび管理タスクを自動化できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス + コンソールアクセスを置き換える: インスタンスへのコンソールアクセス (SSH または RDP) を AWS Systems Manager Run Command に置き換えて、管理タスクを自動化します。 + [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) ## リソース **関連するドキュメント:** + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) + [Replacing a Bastion Host with Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) + [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) **関連動画:** + [Running high-security workloads on Amazon EKS](https://youtu.be/OWRWDXszR-4) + [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) + [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) **関連する例:** + [Lab: Automated Deployment of Web Application Firewall](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) # SEC06-BP06 ソフトウェアの整合性を検証する ワークロードで使用されるソフトウェア、コード、ライブラリが信頼できるソースからのものであり、改ざんされていないことを検証するメカニズム (コード署名など) を実装します。たとえば、バイナリとスクリプトのコード署名証明書を検証して作成者を確認し、作成者が作成してから改ざんされていないことを確認する必要があります。[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) は、署名証明書や パブリックキー、プライベートキーを含むコード署名のライフサイクルを一元管理することで、お客様のコードの信頼性と完全性を確保することができます。コード署名のための高度なパターンとベストプラクティスは、以下で学ぶことができます: [AWS Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/).さらに、ダウンロードするソフトウェアのチェックサムをプロバイダーからのチェックサムと比較し、改ざんされていないことを確認できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + メカニズムを検証する: コード署名は、ソフトウェアの整合性を検証するために使用できるメカニズムの 1 つです。 + [NIST: Security Considerations for Code Signing (コード署名の考慮事項)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01262018.pdf) ## リソース **関連するドキュメント:** + [AWS Signer](https://docs.aws.amazon.com/signer/index.html) + [New – Code Signing, a Trust and Integrity Control for AWS Lambda (New – コード署名、AWS Lambda の信頼性および整合性のコントロール)](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) # データ保護 **Topics** + [SEC 7 データをどのように分類すればよいですか?](w2aac19b7c13b5.md) + [SEC 8 保管時のデータをどのように保護すればよいですか?](w2aac19b7c13b7.md) + [SEC 9 転送時のデータをどのように保護すればよいですか?](w2aac19b7c13b9.md) # SEC 7 データをどのように分類すればよいですか? 分類方法を確立すると、重要度と機密性に基づいてデータをカテゴリ別に分類して、各カテゴリに適した保護と保持方法でデータを管理できるようになります。 **Topics** + [SEC07-BP01 ワークロード内のデータを特定する](sec_data_classification_identify_data.md) + [SEC07-BP02 データ保護コントロールを定義する](sec_data_classification_define_protection.md) + [SEC07-BP03 識別および分類を自動化する](sec_data_classification_auto_classification.md) + [SEC07-BP04 データのライフサイクル管理を定義する](sec_data_classification_lifecycle_management.md) # SEC07-BP01 ワークロード内のデータを特定する ワークロードで処理しているデータの種類と分類、関連するビジネスプロセス、データ所有者、適用される法律・コンプライアンス上の要件、保存場所、結果として実行が必要な統制について理解する必要があります。これには、データが一般公開されることを意図しているかどうか、データが顧客個人識別情報 (PII) などの内部使用のみかどうか、またはデータが知的財産である、法的な秘匿特権がある、機密性が高いと特記されているなど、より制限されたアクセス用であるかどうかを示す分類が含まれます。適切なデータ分類システムを、各ワークロードの保護要件レベルとともに慎重に管理することで、データに適したコントロールとアクセスまたは保護のレベルをマッピングすることができます。たとえば、パブリックコンテンツは誰でもアクセスできますが、重要なコンテンツは暗号化され、コンテンツを復号するためのキーには承認アクセスを要求することで保護しながら保存されます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + Amazon Macie を使用したデータの検出を検討する: Macie は、個人識別情報 (PII) や知的財産などの機密データを認識します。 + [Amazon Macie](Amazon%20Macie%20recognizes%20sensitive%20data%20such%20as%20personally%20identifiable%20information%20(PII)%20or%20intellectual%20property,) ## リソース **関連するドキュメント:** + [Amazon Macie](Amazon%20Macie%20recognizes%20sensitive%20data%20such%20as%20personally%20identifiable%20information%20(PII)%20or%20intellectual%20property,) + [データ分類に関するホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) + [Amazon Macie の開始方法](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) **関連動画:** + [Introducing the New Amazon Macie (新しい Amazon Macie の紹介)](https://youtu.be/I-ewoQekdXE) # SEC07-BP02 データ保護コントロールを定義する 分類レベルに従ってデータを保護します。たとえば、関連するレコメンデーションを使用してパブリックとして分類されたデータを保護すると同時に、追加のコントロールで機密データを保護します。 リソースタグ、機密性ごと (および注意事項、エンクレーブ、関心のあるコミュニティごと) の個別の AWS アカウント 、IAM ポリシー、AWS Organizations SCP、AWS Key Management Service (AWS KMS)、AWS CloudHSM を使用することで、暗号化によるデータ分類と保護のポリシーを定義および実装できます。たとえば、非常に重要なデータを含む S3 バケット、または、秘密データを処理する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを含むプロジェクトがある場合、それらに `「Project=ABC」` を付けることができます。直属のチームのみがこのプロジェクトコードの意味を知っていて、属性ベースのアクセス統制手段を使用する方法を提供します。キーポリシーと許可を使用して AWS KMS 暗号化キーへのアクセスレベルを定義し、安全なメカニズムを通じて適切なサービスだけが機密コンテンツにアクセスできるようにします。タグに基づいて承認決定を判断する場合、AWS Organizations 内のタグポリシーを使用して、タグの許可が適切に定義されていることを確認する必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + データの識別および分類スキーマを定義する: データの識別と分類は、保存するデータの潜在的な影響とタイプ、およびデータにアクセスできるユーザーを評価するために実行されます。 + [AWS ドキュメント](https://docs.aws.amazon.com/) + 利用可能な AWS のコントロールを確認する: 使用しようとしているか、使用を計画している AWS サービスについて、セキュリティコントロールを確認します。多くのサービスには、ドキュメントにセキュリティセクションがあります。 + [AWS ドキュメント](https://docs.aws.amazon.com/) + AWS コンプライアンスリソースを特定する: 支援のために使用できる AWS のリソースを特定します。 + [https://aws.amazon.com/compliance/](https://aws.amazon.com/compliance/?ref=wellarchitected) ## リソース **関連するドキュメント:** + [AWS ドキュメント](https://docs.aws.amazon.com/) + [データ分類に関するホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) + [Amazon Macie の開始方法](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) + [欠落テキスト](https://aws.amazon.com/compliance/) **関連動画:** + [Introducing the New Amazon Macie](https://youtu.be/I-ewoQekdXE) # SEC07-BP03 識別および分類を自動化する データの識別と分類を自動化すると、適切な統制を実装するのに役立ちます。人が直接アクセスするよりも自動化した方が、人為的ミスや開示リスクは小さくなります。など、 [Amazon Macie](https://aws.amazon.com/macie/)などの、機械学習を使用して AWS の機密データを自動的に検出、分類、保護するツールの利用を評価する必要があります。Amazon Macie は個人識別情報 (PII) や知的財産などの機密データを 認識し、このデータへのアクセスや移動の状況を可視化するダッシュボードやアラートを提供します。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス + Amazon Simple Storage Service (Amazon S3) インベントリを使用する: Amazon S3 インベントリは、オブジェクトのレプリケーションと暗号化ステータスの監査とレポートに使用できるツールの 1 つです。 + [Amazon S3 インベントリ](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) + Amazon Macie を検討する: Amazon Macie は、機械学習を使用して Amazon S3 内に保存されているデータを自動的に検出、分類します。 + [Amazon Macie](https://aws.amazon.com/macie/) ## リソース **関連するドキュメント:** + [Amazon Macie](https://aws.amazon.com/macie/) + [Amazon S3 インベントリ](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) + [データ分類に関するホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) + [Amazon Macie の開始方法](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) **関連動画:** + [Introducing the New Amazon Macie (新しい Amazon Macieの紹介)](https://youtu.be/I-ewoQekdXE) # SEC07-BP04 データのライフサイクル管理を定義する 定義されるライフサイクル戦略は、機密性レベル、また法的および組織の要件に基づいている必要があります。データを保持する期間、データ破壊プロセス、データアクセス管理、データ変換、データ共有などの側面を考慮する必要があります。データ分類方法を選択するときは、可用性とアクセスのバランスを取ります。また、各レベルにとって安全でありながら使いやすい方式を採用するために、複数レベルのアクセスと微妙な差異も実装する必要がります。常に多層防御方式を採用し、データおよびデータの変換、削除、コピーのメカニズムに人間がアクセスする機会を減らします。例えば、アプリケーション認証を厳格にし、遠距離操作を実行するために必要なアクセス許可をユーザーでなくアプリケーションに付与します。さらに、ユーザーが信頼できるネットワークパスからアクセスしていることを確認して、復号鍵へのアクセスを要求します。ユーザーにデータへの直接アクセス権を付与するのではなく、ダッシュボードや自動レポートなどのツールを使用して、データからの情報をユーザーに提供します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス + データタイプを識別する: ワークロードに保存または処理するデータのタイプを特定します。そのデータは、テキスト、イメージ、バイナリデータベースなどが考えられます。 ## リソース **関連するドキュメント:** + [データ分類に関するホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) + [Amazon Macie の開始方法](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) **関連動画:** + [新しい Amazon Macie の導入](https://youtu.be/I-ewoQekdXE) # SEC 8 保管時のデータをどのように保護すればよいですか? 複数のコントロールを実装して保管中のデータを保護し、不正アクセスや不正処理のリスクを低減します。 **Topics** + [SEC08-BP01 安全なキー管理を実装する](sec_protect_data_rest_key_mgmt.md) + [SEC08-BP02 保管中に暗号化を適用する](sec_protect_data_rest_encrypt.md) + [SEC08-BP03 保管時のデータの保護を自動化する](sec_protect_data_rest_automate_protection.md) + [SEC08-BP04 アクセスコントロールを適用する](sec_protect_data_rest_access_control.md) + [SEC08-BP05 人をデータから遠ざけるメカニズムを使用する](sec_protect_data_rest_use_people_away.md) # SEC08-BP01 安全なキー管理を実装する キーの保存、ローテーション、アクセス制御を含む暗号化アプローチを定義することで、不正ユーザーからのコンテンツの保護や、正規ユーザーへの不必要な公開を防止することができます。AWS Key Management Service (AWS KMS) は暗号化キーの管理をサポートして [多数の AWS のサービスと統合します](https://aws.amazon.com/kms/details/#integration).このサービスでは、AWS KMS キーのための、耐久性と安全性が高く、冗長なストレージを利用できます。キーのエイリアスのほか、キーレベルのポリシーも定義できます。ポリシーは、キー管理者やキーユーザーを定義するのに役立ちます。さらに、AWS CloudHSM はクラウドベースのハードウェアセキュリティモジュール (HSM) であり、AWS クラウド 上で独自の暗号化キーを簡単に生成して使用できます。FIPS 140-2 レベル 3 検証済みの HSM を使用することで、データセキュリティに関する企業、契約、規制のコンプライアンス要件を満たすことができます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS KMS を実装する: AWS KMS は、キーを作成および管理し、さまざまな AWS のサービスおよびアプリケーションで暗号化の使用を制御することを容易にします。AWS KMS は、FIPS 140-2 で検証されたハードウェアセキュリティモジュールを使用してキーを保護する、安全で弾力性のあるサービスです。 + [Getting started: AWS Key Management Service (AWS KMS) (AWS Key Management Service (AWS KMS) の使用を開始)](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) + AWS Encryption SDK を検討する: アプリケーションでクライアント側でのデータ暗号化が必要な場合、AWS KMS が統合された AWS Encryption SDK を使用します。 + [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) ## リソース **関連するドキュメント:** + [AWS Key Management Service](https://aws.amazon.com/kms) + [AWS cryptographic services and tools (AWS 暗号化サービスとツール)](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) + [Getting started: AWS Key Management Service (AWS KMS) (AWS Key Management Service (AWS KMS) の使用を開始)](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) + [暗号化を使用した Amazon S3 データの保護](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) **関連動画:** + [How Encryption Works in AWS (AWS での暗号化のしくみ)](https://youtu.be/plv7PQZICCM) + [Securing Your Block Storage on AWS (AWS でブロックストレージを保護する)](https://youtu.be/Y1hE1Nkcxs8) # SEC08-BP02 保管中に暗号化を適用する データを保存する唯一の方法は、暗号化を使用することだということを確実にする必要があります。AWS Key Management Service (AWS KMS) は、保管中のすべてのデータをより簡単に暗号化できるように、多数の AWS のサービスとシームレスに統合します。例えば Amazon Simple Storage Service (Amazon S3) では、 [デフォルトの暗号化を](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) バケットに設定して、すべての新しいオブジェクトが自動的に暗号化されるようにすることができます。さらに、[Amazon Elastic Compute Cloud (Amazon EC2) ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)および [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) は、デフォルト暗号化を設定することにより、暗号化の適用をサポートしています。専用のインフラストラクチャで [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) を使用して、例えば次の項目に対して暗号化を使用していることを自動的に確認できます: [Amazon Elastic Block Store (Amazon EBS) ボリューム](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html)io1 [Amazon Relational Database Service (Amazon RDS) インスタンス](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)、および [Amazon S3 バケット](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + Amazon Simple Storage Service (Amazon S3) に対して保管中に暗号化を適用する: Amazon S3 バケットのデフォルト暗号化を実施します。 + [S3 バケットに対してデフォルトの暗号化を有効にするにはどうすればよいですか。](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html) + AWS Secrets Manager を使用する: Secrets Manager は、機密情報の管理を容易にする AWS のサービスです。シークレットとは、データベース認証情報、パスワード、サードパーティ API キー、任意のテキストなどです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) + 新しい EBS ボリュームのデフォルトの暗号化を設定する: 新しく作成したすべての EBS ボリュームを暗号化形式で作成することを指定します。AWS が提供するデフォルトキーを使用するか、作成したキーを使用するかを選択できます。 + [EBS ボリュームのデフォルトの暗号化](https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-volumes/) + 暗号化された Amazon Machine Image (AMI) を設定する: 暗号化を有効化して既存の AMI をコピーすると、自動的にルートボリュームとスナップショットが暗号化されます。 + [暗号化されたスナップショットを持つ AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIEncryption.html) + Amazon Relational Database Service (Amazon RDS) 暗号化を設定する: 暗号化オプションを有効化して、保管中の Amazon RDS データベースクラスターとスナップショットに対して暗号化を設定します。 + [Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html) + 追加の AWS サービス: 使用する AWS のサービスについて、暗号化機能を決定します。 + [AWS ドキュメント](https://docs.aws.amazon.com/) ## リソース **関連するドキュメント:** + [暗号化されたスナップショットを持つ AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIEncryption.html) + [AWS Crypto Tools](https://docs.aws.amazon.com/aws-crypto-tools) + [AWS ドキュメント](https://docs.aws.amazon.com/) + [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) + [AWS KMS 暗号化の詳細についてのホワイトペーパー](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) + [AWS Key Management Service](https://aws.amazon.com/kms) + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) + [AWS 暗号化サービスとツール](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) + [Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) + [EBS ボリュームのデフォルトの暗号化](https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-volumes/) + [Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) + [S3 バケットに対してデフォルトの暗号化を有効にするにはどうすればよいですか。](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html) + [暗号化を使用して Amazon S3 データを保護する](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) **関連動画:** + [AWS での暗号化のしくみ](https://youtu.be/plv7PQZICCM) + [AWS でブロックストレージを保護する](https://youtu.be/Y1hE1Nkcxs8) # SEC08-BP03 保管時のデータの保護を自動化する 自動化ツールを使用して保管中のデータの制御を継続的に検証し、強化します。例えば、すべてのストレージリソースが暗号化されていることを確認します。また、 [すべての EBS ボリューム](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html) が [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)。[AWS Security Hub CSPM](http://aws.amazon.com/security-hub/) は、セキュリティ標準に対する自動チェック機能を通じて、いくつかの制御を検証することもできます。さらに AWS Config ルール は、自動的に [非準拠のリソースを修復できます](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html#setup-autoremediation). **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス *保管中のデータ* とは、ワークロードの任意の期間に永続的ストレージに保持されるすべてのデータを指します。たとえば、ブロックストレージ、オブジェクトストレージ、データベース、アーカイブ、IoT デバイス、データが保持されているその他のストレージ媒体などがあります。暗号化と適切なアクセスコントロールが実装されている場合は、保管中のデータを保護することで不正アクセスのリスクを軽減できます。 保管中に暗号化を適用する: データを保存する唯一の方法は、暗号化を使用することだということを確実にする必要があります。AWS KMS は、保管中のすべてのデータをより簡単に暗号化できるように、多数の AWS のサービスとシームレスに統合します。例えば、Amazon Simple Storage Service (Amazon S3) では、 [デフォルトの暗号化を](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) バケットに設定して、すべての新しいオブジェクトが自動的に暗号化されるようにすることができます。さらに、[Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) および [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) は、デフォルト暗号化を設定することにより、暗号化の適用をサポートしています。専用のインフラストラクチャで [AWS マネージド Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) を使用して、例えば次の項目に対して暗号化を使用していることを自動的に確認できます: [EBS ボリューム](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html)io1[Amazon Relational Database Service (Amazon RDS) インスタンス](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)、および [Amazon S3 バケット](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). ## リソース **関連するドキュメント:** + [AWS Crypto Tools](https://docs.aws.amazon.com/aws-crypto-tools) + [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) **関連動画:** + [AWS での暗号化のしくみ](https://youtu.be/plv7PQZICCM) + [AWS でブロックストレージを保護する](https://youtu.be/Y1hE1Nkcxs8) # SEC08-BP04 アクセスコントロールを適用する 最低限の権限によるアクセスコントロールや、バックアップ、分離、バージョニングなどのメカニズムを適用することは、保管中のデータの保護に役立ちます。オペレーターがデータへのパブリックアクセスを許可しないようにします。 アクセス (最小特権を使用)、バックアップ ( [信頼性ホワイトペーパーを参照](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html))、隔離およびバージョニングなどのさまざまなコントロールはすべて、保管中のデータを保護するのに役立ちます。データへのアクセスは、CloudTrail などのこのホワイトペーパーで前述した探査メカニズムと、Amazon Simple Storage Service (Amazon S3) アクセスログなどのサービスレベルログを使用して監査する必要があります。パブリックにアクセス可能なデータをインベントリし、時間の経過とともに利用可能なデータ量の削減を可能にする方法を計画する必要があります。Amazon Glacier のボールトロックと Amazon S3 オブジェクトロックは、必須のアクセス制御を提供する機能です。ボールトポリシーがコンプライアンスオプションを使用してロックされると、ロックの有効期限が切れるまではルートユーザーでも変更できません。このメカニズムは、SEC、CFTC、FINRA の帳簿および記録管理要件を満たしています。詳細については、 [このホワイトペーパーを参照してください](https://d1.awsstatic.com/whitepapers/Amazon-GlacierVaultLock_CohassetAssessmentReport.pdf). **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス + アクセスコントロールを適用する: 暗号キーへのアクセスを含め、最小権限を用いたアクセスコントロールを適用します。 + [Amazon S3 リソースへのアクセス許可の管理の導入](https://docs.aws.amazon.com/AmazonS3/latest/dev/intro-managing-access-s3-resources.html) + さまざまな分類レベルに基づいてデータを分離する: AWS Organizations によって管理されるデータ分類レベルには、さまざまな AWS アカウント アカウントを使用します。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) + AWS KMS ポリシーをレビューする: AWS KMS ポリシーで付与されるアクセスのレベルを確認します。 + [AWS KMS リソースへのアクセス管理の概要](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) + Amazon S3 バケットとオブジェクトアクセス許可をレビューする: Amazon S3 バケットのポリシーで付与されるアクセスのレベルを定期的に確認します。ベストプラクティスは、バケットを公開で読み取りまたは書き込み可能にしないことです。AWS Config を使用して公開されているバケットを検出し、Amazon CloudFront を使用して Amazon S3 からコンテンツを提供することを検討します。 + [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) + [Amazon S3 \$1 Amazon CloudFront: 理想的な組み合わせ](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/) + Amazon S3 バージョニングとオブジェクトロックを有効にします。 + [バージョニングの使用](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) + [Amazon S3 Object Lock を使ってオブジェクトをロックする](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html) + Amazon S3 インベントリを使用する: Amazon S3 インベントリは、オブジェクトのレプリケーションと暗号化ステータスの監査とレポートに使用できるツールの 1 つです。 + [Amazon S3 インベントリ](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) + Amazon EBS および AMI 共有アクセス許可をレビューする: 共有アクセス許可は、イメージとボリュームをワークロード外の AWS アカウント に共有することを可能にします。 + [Amazon EBS スナップショットの共有](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) + [共有 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html) ## リソース **関連するドキュメント:** + [AWS KMS 暗号化の詳細についてのホワイトペーパー](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) **関連動画:** + [AWS でブロックストレージを保護する](https://youtu.be/Y1hE1Nkcxs8) # SEC08-BP05 人をデータから遠ざけるメカニズムを使用する 通常の運用状況で、すべてのユーザーが機密データおよびシステムに直接アクセスできないようにします。たとえば、変更管理ワークフローを使用して、直接アクセスや踏み台ホストを許可する代わりに、ツールを使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理します。これは、タスクを実行する手順を含むオートメションドキュメントを使用する  [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)を通じて [達成できます](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 。これらのドキュメントはソース管理に保存し、実行前にピアレビューを行い、シェルアクセスと比較してリスクを最小限に抑えるために徹底的にテストできます。ビジネスユーザーは、データストアに直接アクセスする代わりにダッシュボードを使用し、クエリを実行できます。CI/CD パイプラインを使用しない場合は、通常無効になっている特権アクセスメカニズムを適切に提供するために必要な制御とプロセスを決定します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス + 人をデータから遠ざけるメカニズムを実装する: メカニズムには、Quick などのダッシュボードを使用して、直接クエリを実行する代わりにユーザーにデータを表示することが含まれます。 + [Quick](https://aws.amazon.com/quicksight/) + 設定管理を自動化する: 設定管理サービスまたはツールを使用して、リモートでアクションを実行し、安全な設定を自動的に適用および検証します。踏み台ホストを使用したり、EC2 インスタンスに直接アクセスしたりすることを回避します。 + [AWS Systems Manager](https://aws.amazon.com/systems-manager/) + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) + [AWS の AWS CloudFormation テンプレートの CI/CD パイプライン](https://aws.amazon.com/quickstart/architecture/cicd-taskcat/) ## リソース **関連するドキュメント:** + [AWS KMS 暗号化の詳細についてのホワイトペーパー](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) **関連動画:** + [How Encryption Works in AWS](https://youtu.be/plv7PQZICCM) + [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) # SEC 9 転送時のデータをどのように保護すればよいですか? 複数のコントロールを実装して、転送中のデータを保護し、不正アクセスや損失のリスクを軽減します。 **Topics** + [SEC09-BP01 安全な鍵および証明書管理を実装する](sec_protect_data_transit_key_cert_mgmt.md) + [SEC09-BP02 伝送中に暗号化を適用する](sec_protect_data_transit_encrypt.md) + [SEC09-BP03 意図しないデータアクセスの検出を自動化する](sec_protect_data_transit_auto_unintended_access.md) + [SEC09-BP04 ネットワーク通信を認証する:](sec_protect_data_transit_authentication.md) # SEC09-BP01 安全な鍵および証明書管理を実装する 暗号化キーと証明書を安全に保存し、厳格なアクセスコントロールによって適切な時間間隔でローテーションします。これを実現する最善の方法として、 [AWS Certificate Manager (ACM)](http://aws.amazon.com/certificate-manager).これにより、AWS のサービスおよび内部接続リソースで使用するためのパブリックおよびプライベートの Transport Layer Security (TLS) 証明書のプロビジョニング、管理、デプロイが容易になります。TLS 証明書は、ネットワーク通信を保護し、プライベートネットワーク上のリソースだけでなく、インターネット上のウェブサイトのアイデンティティを確立するために使用されます。ACM は、Elastic Load Balancers (ELB)、AWS ディストリビューション、API Gateway の API などの AWS リソース と統合し、証明書の自動更新も処理します。Amazon Elastic Compute Cloud を使用してプライベートルート CA をデプロイする場合、証明書とプライベートキーの両方を ACM (Amazon EC2) インスタンス、コンテナなどで使用するために提供できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + 安全な鍵および証明書管理を実装する: 定義された安全なキーおよび証明書管理ソリューションを実装します。 + [AWS Certificate Manager ](https://aws.amazon.com/certificate-manager/) + [AWS でプライベート証明書インフラストラクチャをホストおよび管理する方法 ](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/) + 安全なプロトコルを実装する: 認証と機密性を提供する安全なプロトコル (Transport Layer Security (TLS) や IPsec など) を使用し、データの改ざんや損失のリスクを軽減します。使用しているサービスに関連するプロトコルとセキュリティについては、AWS ドキュメントを参照してください。 ## リソース **関連するドキュメント:** + [AWS ドキュメント ](https://docs.aws.amazon.com/) # SEC09-BP02 伝送中に暗号化を適用する 組織、法律、コンプライアンスの要件を満たすために、適切な基準や 推奨事項に基づいて、定義された暗号化要件を実施します。AWS サービスは、通信に TLS を使用して HTTPS エンドポイントを提供するため、AWS API と通信する際には伝送中に暗号化されます。HTTP などの安全でないプロトコルは、セキュリティグループを使用して VPC で監査およびブロックできます。HTTP リクエストは [自動的に](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) Amazon CloudFront で HTTPS または [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions).コンピューティングリソースを完全に制御して、サービス全体に伝送中データの暗号化を実装できます。また、外部ネットワークからお使いの VPC に VPN で接続して、トラフィックの暗号化を促進できます。特別な要件がある場合は、AWS Marketplace でサードパーティーのソリューションを入手できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス + 伝送中に暗号化を適用する: 暗号化の要件は、最新の標準とベストプラクティスに基づき、安全なプロトコルのみを許可する必要があります。たとえば、Application Load Balancer または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスには、HTTPS プロトコルを許可するセキュリティグループのみを設定します。 + エッジサービスで安全なプロトコルを設定する: Amazon CloudFront と必要な暗号で HTTPS を設定します。 + [ CloudFront で HTTPS を使用する ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) + 外部接続に VPN を使用する: ポイントツーポイント接続やネットワーク間接続を IPsec 仮想プライベートネットワーク (VPN) で保護し、データのプライバシーと整合性の両方を提供することを検討してください。 + [ VPN 接続 ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpn-connections.html) + ロードバランサーで安全なプロトコルを設定する: ロードバランサーへの接続を保護するために、HTTPS リスナーを有効にします。 + [ Application Load Balancer 用の HTTPS リスナー ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) + インスタンスの安全なプロトコルを設定する: インスタンスに HTTPS 暗号化を設定することを検討します。 + [ チュートリアル: Amazon Linux 2 で SSL/TLS を使用できるように Apache ウェブサーバーを設定する ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-an-instance.html) + Amazon Relational Database Service (Amazon RDS) で安全なプロトコルを設定する: Secure Socket Layer (SSL) または Transport Layer Security (TLS) を使って、データベースインスタンスへの接続を暗号化します。 + [ SSL を使用した DB インスタンスへの接続の暗号化 ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) + Amazon Redshift で安全なプロトコルを設定する: クラスターで Secure Socket Layer (SSL) または Transport Layer Security (TLS) 接続が必要となるよう設定します。 + [ 接続のセキュリティオプションを設定する ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html) + 追加の AWS のサービスで安全なプロトコルを設定する: 使用する AWS のサービスについて、転送中の暗号化機能を決定します。 ## リソース **関連するドキュメント:** + [AWS のドキュメント ](https://docs.aws.amazon.com/index.html) # SEC09-BP03 意図しないデータアクセスの検出を自動化する Amazon GuardDuty などのツールを使用して、疑わしい活動や定義された境界外にデータを移動させようとする試みを自動的に検出します。例えば、GuardDuty は Amazon Simple Storage Service (Amazon S3) 読み取りアクティビティを検出できますが、それには [Exfiltration:S3/AnomalousBehavior 調査結果を使用します](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#exfiltration-s3-objectreadunusual).GuardDuty に加えて、ネットワークトラフィック情報をキャプチャする [Amazon VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)を Amazon EventBridge とともに使用して、異常な接続 (成功と拒否の両方) の検出をトリガーできます。[Amazon S3 Access Analyzer](http://aws.amazon.com/blogs/storage/protect-amazon-s3-buckets-using-access-analyzer-for-s3) は Amazon S3 バケット内で誰がどのデータにアクセス可能かを評価するのに役立ちます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 意図しないデータアクセスの検出を自動化する: ツールまたは検出メカニズムを使用し、定義された境界の外側にデータを移動する試みを自動的に検出します。例えば、認識できないホストにデータをコピーしているデータベースシステムを検出します。 + [ VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) + Amazon Macie を検討する: Amazon Macie は、機械学習とパターンマッチングを使用して AWS の機密データを検出および保護する、フルマネージドのデータセキュリティおよびデータプライバシーサービスです。 + [ Amazon Macie ](https://aws.amazon.com/macie/) ## リソース **関連ドキュメント:** + [ VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) + [ Amazon Macie ](https://aws.amazon.com/macie/) # SEC09-BP04 ネットワーク通信を認証する: Transport Layer Security (TLS) や IPsec など、認証をサポートするプロトコルを使用して、通信の ID を検証します。 認証をサポートするネットワークプロトコルを使用すると、当事者間で信頼を確立できます。これにより、プロトコルで使用される暗号化が追加され、通信が変更または傍受されるリスクが軽減します。認証を実装する一般的なプロトコルには、多くの AWS のサービスで使用される Transport Layer Security (TLS) と、 [AWS Virtual Private Network (Site-to-Site VPN) で使用される IPsecがあります](http://aws.amazon.com/vpn). **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス + 安全なプロトコルを実装する: 認証と機密性を提供する安全なプロトコル (Transport Layer Security (TLS) や IPsec など) を使用し、データの改ざんや損失のリスクを軽減します。使用しているサービスに関連するプロトコルとセキュリティについては、 [AWS ドキュメントを](https://docs.aws.amazon.com/) 参照してください。 ## リソース **関連するドキュメント: ** + [AWS ドキュメント](https://docs.aws.amazon.com/) # インシデント対応 **Topics** + [SEC 10 インシデントの予測、対応、復旧はどのように行いますか?](w2aac19b7c15b5.md) # SEC 10 インシデントの予測、対応、復旧はどのように行いますか? 組織に支障をきたすことを最小限に抑えるために、セキュリティインシデントのタイムリーで効果的な調査、対応、復旧に備えることが重要です。 **Topics** + [SEC10-BP01 重要な人員と外部リソースを特定する:](sec_incident_response_identify_personnel.md) + [SEC10-BP02 インシデント管理計画を作成する](sec_incident_response_develop_management_plans.md) + [SEC10-BP03 フォレンジック機能を備える:](sec_incident_response_prepare_forensic.md) + [SEC10-BP04 封じ込め機能を自動化する](sec_incident_response_auto_contain.md) + [SEC10-BP05 アクセスを事前プロビジョニングする](sec_incident_response_pre_provision_access.md) + [SEC10-BP06 ツールを事前デプロイする](sec_incident_response_pre_deploy_tools.md) + [SEC10-BP07 ゲームデーを実施する](sec_incident_response_run_game_days.md) # SEC10-BP01 重要な人員と外部リソースを特定する: 組織がインシデントに対応するのに役立てるため、社内外の担当者、リソース、法的義務を特定します。 クラウド上でのインシデントレスポンスへのアプローチを他のチーム (顧問弁護士、経営陣、ビジネスステークホルダー、AWS サポートサービスなど) と連携して定義する場合、重要な人物、ステークホルダー、関連する担当者を特定する必要があります。依存性を減らし、応答時間を短縮するために、チームや専門のセキュリティチーム、応答者が利用するサービスについて教育を受け、実践的な演習をする機会を持つようにしてください。 対応能力を強化するために、外部の専門知識および異なる視点を備えた社外の AWS セキュリティパートナーを探しておくことをお勧めします。信頼できるセキュリティパートナーは、馴染みのない潜在的なリスクや脅威を特定するのに役立ちます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + 組織内の主要な人員を特定する: インシデント対応と復旧に必要な組織内の人員の連絡先リストを保持します。 + 外部パートナーを特定する: 必要に応じて、インシデント対応と復旧を支援できる外部パートナーと連携します。 ## リソース **関連するドキュメント:** + [AWS インシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) **関連動画:** + [AWS 環境のセキュリティインシデントの準備と対応 ](https://youtu.be/8uiO0Z5meCs) **関連する例:** # SEC10-BP02 インシデント管理計画を作成する インシデントへの応答、インシデント時の伝達、インシデントからの復旧に役立つ計画を作成します。たとえば、ワークロードと組織にとって起こる可能性が最も高いシナリオで、インシデント応答計画を作成してみましょう。内部および外部に伝達およびエスカレーションする方法を含めます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス インシデント管理計画は、セキュリティインシデントの潜在的な影響への対応、復旧、軽減に不可欠です。インシデント管理計画は、セキュリティインシデントをタイムリーに特定し、修復、対応するための体系的なプロセスです。 クラウドには、オンプレミス環境と同じオペレーション上のロールと要件があります。インシデント管理計画を作成する際は、ビジネス成果とコンプライアンス要件と最も合致する対応および復旧戦略を組み込むことが重要です。例えば、米国の FedRAMP 準拠のワークロードを AWS で運用している場合は、 [『NIST SP 800-61 Computer Security Handling Guide』を遵守することが役に立ちます](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf)。同様に、ヨーロッパの PII (個人を特定できる情報) データを含むワークロードを運用しているときは、 [EU 一般データ保護規則 (GDPR) で義務付けられているようにデータレジデンシー関連の問題に対してどのように防御、対応するかといったシナリオを考慮します](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en)。 AWS で運用するワークロードについてインシデント管理計画を策定する際は、 [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)から始め、インシデント対応に向けた多層防御アプローチを構築することを目指します。このモデルでは、AWS はクラウドのセキュリティを管理します。クラウド内のセキュリティについてはお客様の責任です。つまり、お客様はコントロールを保持するとともに、実装しようとするセキュリティコントロールに責任を持つということです。『 [AWS Security Incident Response Guide』(AWS セキュリティインシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) には、クラウド中心のインシデント管理計画を策定するための重要なコンセプトと基本的なガイダンスが記載されています。 効果的なインシデント管理計画は、クラウド運用の目標に沿って継続的に繰り返し、最新の状態に保つ必要があります。インシデント管理計画を作成して進化させるにあたり、以下に記載の実装計画を使用することを検討してください。 + **インシデント対応の教育とトレーニング: ** 定義されたベースラインからの逸脱 (間違ったデプロイ、設定ミスなど) が発生した場合は、対応と調査が必要になる可能性があります。これを適切に行うために、自社の AWS 環境内でセキュリティインシデント対応に使用できるコントロールと機能を理解するとともに、インシデント対応に関与するクラウドチームの準備を整え、教育とトレーニングを行うプロセスを把握する必要があります。 + [プレイブック](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) および [ランブック](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) は、インシデントへの対応方法のトレーニングで一貫性を確保するのに効果的なメカニズムです。まず、インシデント対応中に頻繁に実行する手順の最初のリストを作成し、継続的に繰り返しながら新しい手順の学習や採用を行います。 + スケジュールされた [ゲームデーをとおして、プレイブックとランブックを広めます](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)。ゲームデーの期間中、制御された環境でインシデント対応をシミュレーションします。それにより、チームは対応方法を思い出し、インシデント対応に関与する各チームがワークフローを熟知していることを検証できます。シミュレーションされたイベントの結果をレビューし、改善点を特定し、さらにトレーニングや追加ツールが必要か判断します。 + セキュリティは全員の任務と見なす必要があります。普段、ワークロードを運用するすべてのスタッフを関与させることで、インシデント管理プロセスの集合知を構築します。これにはビジネスのすべての側面、つまり、運用、テスト、開発、セキュリティ、ビジネスオペレーション、ビジネスリーダーが含まれます。 + **インシデント管理計画をドキュメント化する: ** アクティブなインシデントの記録、対応、進捗に関するコミュニケーション、通知の提供のためのツールとプロセスをドキュメント化します。インシデント管理計画の目標は、通常のオペレーションができるだけ迅速に復旧され、ビジネスへの影響が最小限に抑えられ、すべての関係者に情報が提供されることを検証することです。インシデントの例としては、ネットワーク接続の損失やパフォーマンス低下、応答しないプロセスまたは API、スケジュール済みだが実行されないタスク (パッチ適用の失敗など)、アプリケーションデータまたはサービスの利用不可、セキュリティイベントに起因する計画外のサービス中断、認証情報の漏洩、設定ミスによるエラーがあります (ただし、これらに限定されません)。 + インシデント解決に責任を持つ主な所有者 (ワークロード所有者など) を特定します。誰がインシデントを管理するか、またどのようにコミュニケーションを取るかについて、明確なガイダンスを用意します。外部ベンダーなど複数の当事者をインシデント解決プロセスに関与させる場合は、インシデント解決で求められる、さまざまなチームやスタッフの役割と責任を記述した *責任分担 (RACI) マトリックス*を作成することを検討します。 RACI マトリックスには以下を記述します。 + **R: ** *Responsible * - 作業を行いタスクを完了する実行責任者。 + **A: ** *Accountable * - 指定されたタスクの正常な完了に対して最終的な権限を持つ説明責任者またはステークホルダー。 + **C: ** *Consulted * - 意見を求められる相談先。一般的には対象分野の専門家。 + **I: ** *Informed * - 進捗について通知を受ける情報提供先。多くの場合、タスクの完了や成果物についてのみ通知される。 + **インシデントを分類する: ** インシデントを定義し、重大度と影響度のスコアに基づき分類することで、インシデントをトリアージして解決するための体系的なアプローチが可能となります。次の推奨事項は、インシデントを数値化するための *影響と解決の緊急マトリックス* を説明するものです。例えば、影響度: 低、緊急度: 低のインシデントは、重大度: 低のインシデントと見なされます。 + **高 (H): ** ビジネスは多大な影響を受けます。AWS リソースに関連するアプリケーションのクリティカルな機能は使用できません。本番システムに影響を及ぼすほとんどのクリティカルイベントのために用意されています。インシデントの影響は急速に拡大し、修復には時間的制約があります。 + **中 (M): ** AWS リソースに関連するビジネスサービスまたはアプリケーションは、適度に影響を受けますが、パフォーマンスが低下した状態で機能します。サービスレベル目標 (SLO) に寄与するアプリケーションは、サービスレベルアグリーメント (SLA) の範囲内で影響を受けます。システムは、能力が低下した状態で機能することができ、財務的影響および評判上の影響はあまりありません。 + **低 (L): ** AWS リソースに関連するビジネスサービスまたはアプリケーションの非クリティカルな機能が影響を受けます。システムは、能力が低下した状態で機能することができ、財務的影響および評判上の影響は最小限にとどまります。 + **セキュリティコントロールを標準化する: ** セキュリティコントロールを標準化する目的は、オペレーションの結果に関する一貫性、トレーサビリティ、再現性を実現することです。インシデント対応に欠かせない重要なアクティビティについて標準化を推進します。以下に例を挙げます。 + **アイデンティティとアクセスの管理: ** データへのアクセスを制御し、人間とマシンアイデンティティの両方の権限を管理するためのメカニズムを確立します。シングルサインオンとロールベースの権限を含むフェデレーテッドセキュリティを使用して、貴社独自のアイデンティティとアクセスの管理をクラウドに拡張し、アクセス管理を最適化します。アクセス管理を標準化するためのベストプラクティスの推奨事項と改善計画については、 [セキュリティの柱に関するホワイトペーパーの「ID とアクセス管理」のセクション](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) を参照してください + **脆弱性管理: ** AWS 環境で、攻撃者がシステムを侵害、悪用するために用いる可能性のある脆弱性を特定するためのメカニズムを確立します。予防的コントロールと発見的コントロールの両方をセキュリティメカニズムとして実装し、セキュリティインシデントの潜在的な影響に対応し、その影響を緩和します。脅威のモデル化などのプロセスを、インフラストラクチャ構築およびアプリケーションデリバリーライフサイクルの一環として標準化します。 + **構成管理: ** 標準構成を定義し、AWS クラウド にリソースをデプロイする手順を自動化します。インフラストラクチャとリソースの両方のプロビジョニングを標準化すると、間違ったデプロイによる設定ミスや意図しない人的な設定ミスのリスクの軽減に役立ちます。このコントロールを実装するためのガイダンスと改善計画については、『運用上の優秀性の柱』のホワイトペーパーの [「設計原則」のセクション](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) を参照してください。 + **監査コントロールのためのログ記録と監視: ** リソースの障害、パフォーマンス低下、セキュリティの問題を監視するためのメカニズムを実装します。これらのコントロールを標準化すると、システムで発生したアクティビティの監査証跡が提供され、問題のタイムリーなトリアージと修復に役立ちます。SEC04 [(「セキュリティイベントは、どのように検出して調査するのですか?」) のベストプラクティスは、](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) このコントロールを実装するためのガイダンスを提供しています。 + **オートメーションを使用する: ** オートメーションにより、インシデントのタイムリーで大規模な解決が可能となります。AWS は、インシデント対応戦略の枠組みの中で自動化を行うサービスを複数提供しています。オートメーションと人の介入との適切なバランスを見つけることに重点を置きます。プレイブックとランブックでインシデント対応を構築しながら、繰り返し可能なステップを自動化します。AWS Systems Manager Incident Manager などの AWS サービスを使用して [IT インシデントの解決を迅速化します](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/)。デベロッパーツールを [使用して、](https://aws.amazon.com/devops/) バージョン管理を提供し、[Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) と Infrastructure as Code (IaC) のデプロイを自動化し、人間の介入を排除します。該当する場合は、Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、AWS Config、Amazon Macie などのマネージドサービスを使用して検出とコンプライアンス評価を自動化します。Amazon DevOps Guru などの機械学習を使用して検出機能を最適化し、異常な動作パターンの問題が発生する前に検出します。 + **根本原因分析と、教訓から得られたアクションを実施します。** 過去のインシデント対応レビューの一環として、教訓を取り込むためのメカニズムを実装します。インシデントの根本原因により、より大規模な検出、設計上の欠陥、設定ミス、再発の可能性が明らかになった場合、問題として分類されます。そのような場合、問題を分析および解決して、通常のオペレーションの中断を最小限に抑えます。 ## リソース **関連するドキュメント:** + [AWS Security Incident Response Guide (AWS セキュリティインシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) + [ NIST: Computer Security Incident Handling Guide ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) **関連動画:** + [AWS のインシデント対応とフォレンジックの自動化 ](https://youtu.be/f_EcwmmXkXk) + [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [AWS 環境のセキュリティインシデントの準備と対応 ](https://www.youtube.com/watch?v=8uiO0Z5meCs) **関連サンプル:** + [ラボ : Jupyter を使用したインシデント対応プレイブック - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) + [ ラボ: Incident Response with AWS Console and CLI (AWS コンソールと CLI を使用したインシデント対応) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/) # SEC10-BP03 フォレンジック機能を備える: インシデントレスポンダーがフォレンジック調査が対応計画に適合する時期と方法を理解しておくことが重要です。組織は収集される証拠と、プロセスで使用されるツールを定義する必要があります。外部のスペシャリスト、ツール、オートメーションなど、適切なフォレンジック調査能力を特定し、準備します。前もって下す重要な決定は、ライブシステムからデータを収集するかどうかです。システムの電源を切ったり再起動したりすると、揮発性メモリの内容やアクティブなネットワーク接続などの一部のデータが失われます。 対応チームは、AWS Systems Manager、Amazon EventBridge、および AWS Lambda などのツールを組み合わせて、オペレーティングシステムおよびトラフィックミラーリング内でフォレンジックツールを実行し、ネットワークパケットキャプチャを取得し、非永続的証拠を収集できます。ログ分析やディスクイメージの分析などその他のアクティビティは、レスポンダーがアクセスできるカスタマイズされたフォレンジックワークステーションとツールを備えた専用のセキュリティアカウントで実行します。 関連ログは、高い耐久性と整合性を提供するデータストアに定期的に送信します。レスポンダーは、それらのログにアクセスできる必要があります。AWS には、Amazon Athena、Amazon OpenSearch Service (OpenSearch Service)、および Amazon CloudWatch Logs Insights などログ調査をやりやすくするツールがいくつかあります。さらに、Amazon Simple Storage Service (Amazon S3) Object Lock を使って安全に証拠を保持します。このサービスは WORM (write-once- read-many) モデルに従っており、定義済みの期間オブジェクトが検出されたり上書きされたりするのを防ぎます。フォレンジック調査技術には専門的なトレーニングが必要なため、外部のスペシャリストとの連携が必要になる場合があります。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + フォレンジック機能を確認する: 組織のフォレンジック調査機能、利用可能なツール、外部スペシャリストを調査します。 + [インシデント対応とフォレンジックの自動化 ](https://youtu.be/f_EcwmmXkXk) ## リソース **関連するドキュメント:** + [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) # SEC10-BP04 封じ込め機能を自動化する インシデントの封じ込めおよび復旧を自動化し、対応時間を短縮するとともに組織的影響を軽減します。 プレイブックからプロセスやツールを作成して実践したら、ロジックをコードベースのソリューションに分解します。そうすることによって、多くの応答者が応答を自動化し、応答者によるばらつきや推測作業を取り除くためのツールとして使用することができます。これにより、対応のライフサイクルを高速化できます。次の目標は、このコードを人間の対応者ではなく、アラートやイベント自体によって呼び出すことで完全な自動化を実現し、イベント駆動型の対応を有効にすることです。これらのプロセスではまた、セキュリティシステムに関連データを自動的に追加する必要があります。たとえば、希望しない IP アドレスからのトラフィックが関与するインシデントが起こると、AWS WAF ブロックリストまたは Network Firewall ルールグループに自動的に入力されて、それ以上のアクティビティが防止されます。 ![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png) *図 3: AWS WAF が既知の悪意ある IP アドレスのブロックを自動化します。* イベント駆動型の対応システムでは、検出メカニズムによって対応メカニズムがトリガーされ、自動的にイベントが修正されます。イベント駆動型の応答機能を使用すれば、検出メカニズムから応答メカニズムが動作するまでの時間を短縮できます。このイベント駆動型アーキテクチャを作成するには、AWS Lambda を使用できます。AWS Lambda は、イベントに応答してコードを実行し、基盤となるコンピューティングリソースを自動的に管理するサーバーレスコンピューティングサービスです。例えば、AWS CloudTrail サービスが有効な AWS アカウントがあるとします。AWS CloudTrail が無効になっている場合は `(cloudtrail:StopLogging API 呼び出しを通じて)、` Amazon EventBridge を使用して特定の `(cloudtrail:StopLogging API 呼び出しを通じて)、` イベントをモニタリングし、 AWS Lambda 関数を起動して `cloudtrail:StartLogging` を呼び出してログを再開できます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス 封じ込め機能を自動化します。 ## リソース **関連するドキュメント:** + [AWS インシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) **関連動画:** + [AWS 環境のセキュリティインシデントの準備と対応](https://youtu.be/8uiO0Z5meCs) # SEC10-BP05 アクセスを事前プロビジョニングする インシデント対応者が AWS に事前プロビジョニングされた正しいアクセス権を持っていることを検証しておき、調査から復旧までに必要な時間を短縮します。 **一般的なアンチパターン:** + ルートアカウントをインシデント対応に使用する + 既存のユーザーアカウントに変更を加える + ジャストインタイムの権限昇格を提供する際に IAM アクセス許可を直接操作する **このベストプラクティスが確立されていない場合のリスクレベル:** 中 ## 実装のガイダンス AWS は、可能であれば長期的な認証情報への依存を削減または排除し、一時的な認証情報と *ジャストインタイム* の権限昇格メカニズムを優先することを推奨します。長期的な認証情報は、セキュリティリスクにさらされやすく、オペレーションのオーバーヘッドを増大させます。ほとんどの管理タスクと、インシデント対応タスクについては、管理アクセスの一時的な昇格と併せて [ID フェデレーション](https://docs.aws.amazon.com/identity/federation/) を実装することを [お勧めします](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。このモデルでは、ユーザーはより高いレベルの権限 (インシデント対応ロールなど) への昇格をリクエストします。ユーザーに昇格の資格がある場合、リクエストは承認者に送信されます。リクエストが承認された場合、ユーザーは、一時的な [AWS 認証情報](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) のセットを受け取り、これを使用してタスクを完了できます。これらの認証情報の期限が切れたら、ユーザーは新たな昇格リクエストを送信する必要があります。 インシデント対応の大半のケースでは、一時的な権限昇格を使用することをお勧めします。そのための適切な方法は、 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) および [セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) を使用してアクセスのスコープを定義することです。 ID フェデレーションを使用できないケースがあります。例えば次のケースです。 + 侵害を受けた ID プロバイダー (IdP) に関連する停止状態 + 設定ミスや人的エラーに起因する、フェデレーションアクセス管理システムの障害 + 分散型サービス拒否 (DDoS) イベントやシステムがレンダリング不可となるなどの悪意あるアクティビティ 上記のケースでは、緊急 *break glass * アクセス設定により、インシデントの調査とタイムリーな修復を許可する必要があります。AWS は、 [適切なアクセス許可を持つ IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) を使用することをお勧めします。IAM ユーザーがタスクを実行し AWS のリソースにアクセスするための適切な許可を付与します。ルート認証情報は、 [ルートユーザーアクセスが必要なタスク](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)のみに使用します。インシデント対応者が AWS と他の関連システムへの適切なレベルのアクセス権を持っていることを検証するには、専用のユーザーアカウントへの事前プロビジョニングをお勧めします。このユーザーアカウントには特権アクセスが必要で、アカウントは厳格に制御、監視されなければなりません。このアカウントは、必要なタスクの実行で要求される最小特権で構成しなければなりません。アクセス権のレベルは、インシデント管理計画の一環として作成されたプレイブックに基づいている必要があります。 ベストプラクティスとして、特定の目的のための専用のユーザーとロールを使用します。IAM ポリシーの追加によりユーザーまたはロールアクセスを一時的に昇格させると、インシデント対応中にユーザーがどのアクセス権を持っていたかが明確でなくなり、昇格された権限が取り消されないリスクが生じます。 できるだけ多くの依存関係を削除し、できるだけ多くの障害シナリオでアクセスが可能になることを検証することが重要です。そのためには、インシデント対応ユーザーが、専用のセキュリティアカウントで AWS Identity and Access Management ユーザーとして作成されており、既存のフェデレーションまたはシングルサインオン (SSO) ソリューションにより管理されていないことを検証するためのプレイブックを作成します。個々のインシデント対応者は、自分の名前が付いたアカウントを持つ必要があります。アカウント設定では、 [強力なパスワードポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) および多要素認証 (MFA) を適用する必要があります。インシデント対応プレイブックで AWS マネジメントコンソール へのアクセスのみが要求されている場合、そのユーザーのアクセスキーが設定されてはならず、アクセスキー作成を明示的に禁止する必要があります。これは IAM ポリシーまたはサービスコントロールポリシー (SCP) で設定できます。詳細は、『AWS Security Best Practices for [AWS Organizations SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)』(AWS Organizations SCP のための AWS セキュリティベストプラクティス) に記載されています。ユーザーは、他のアカウントのインシデント対応ロールを引き受ける以外の権限を持つべきではありません。 インシデント対応中、調査、修復、または復旧アクティビティをサポートするためのアクセス権を社内または社外の他の個人に付与する必要が生じる可能性があります。この場合、前述のプレイブックメカニズムを使用します。また、インシデント完結後直ちに追加のアクセス権を取り消すためのプロセスが必要です。 インシデント対応ロールの使用が適切に監視および監査されていることを検証するには、この目的のために作成された IAM ユーザーアカウントが個人間で共有されないようにすること、および特定のタスクで必要な場合を除き、AWS アカウント ルートユーザーが使用されないようにすることが [不可欠です](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。ルートユーザーが必要な場合 (例えば、特定のアカウントへの IAM アクセスが利用できない場合) は、用意されたプレイブックに従って別個のプロセスを使用し、ルートユーザーのパスワードと MFA トークンの使用の可否を検証します。 インシデント対応ロールのための IAM ポリシーを設定するには、 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) を使用し AWS CloudTrail ログに基づいてポリシーを生成することを検討します。そのためには、非本番アカウントのインシデント対応ロールに管理者アクセス権を付与し、プレイブックを一通り実行します。完了したら、実行されたアクションのみを許可するポリシーを作成できます。このポリシーは、すべてのアカウントのすべてのインシデント対応ロールに適用できます。各プレイブックについて個別の IAM ポリシーを作成すると、管理と監査が容易になるでしょう。プレイブックの例には、ランサムウェア、データ侵害、本番環境へのアクセス不可、その他のシナリオについての対応計画が含まれています。 インシデント対応ユーザーアカウントを使用して、 [別の AWS アカウント アカウントのインシデント対応専用の IAM ロールを引き受けます](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。これらのロールは、セキュリティアカウントのユーザーのみが引き受け可能なように設定する必要があります。信頼関係では、呼び出しプリンシパルが MFA を使用して認証されたことを要求する必要があります。ロールは、スコープが厳密に定義された IAM ポリシーを使用してアクセスを制御する必要があります。これらのロールに対するすべての `AssumeRole` リクエストが CloudTrail ログに記録され、アラートが送信されるようにします。また、これらのロールを使用して実行されたアクションがログに記録されるようにします。 IAM ユーザーアカウントと IAM ロールの両方を CloudTrail ログで見つけやすくするために、これらに明快な名前を付けることを強くお勧めします。例えば、IAM アカウントに `break-glass` 、IAM ロールに `BREAK-GLASS-ROLE` という名前を付けます。 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) を使用して、AWS アカウントの API アクティビティをログに記録します。また、 [インシデント対応ロールの使用状況に関するアラートを設定する](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)必要があります。ルートキーを使用する際のアラートの設定に関するブログ記事を参照してください。インストラクションに変更を加えて、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) メトリクスフィルターを `AssumeRole` イベント (インシデント対応 IAM ロールに関連する) に対して設定できます。 ``` { $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" } ``` インシデント対応ロールは高いレベルのアクセス権を持っている可能性があるため、これらのアラートは幅広いグループに送信され、速やかに対応が取られることが重要です。 インシデント対応中、対応者は、IAM によって直接保護されていないシステムへのアクセスが必要となる可能性があります。これには Amazon Elastic Compute Cloud インスタンス、Amazon Relational Database Service データベース、Software-as-a-Service (SaaS) プラットフォームが含まれます。SSH や RDP などのネイティブプロトコルではなく、[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) を使用して Amazon EC2 インスタンスへの管理アクセスを行うことを強くお勧めします。このアクセスは、IAM を使用して制御できます。それにより安全が確保され、監査が行われます。また、 [AWS Systems Manager Run Command ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)を使用してプレイブックの一部を自動化することも可能です。それにより、ユーザーのエラーを減らし、復旧にかかる時間を短縮できます。データベースとサードパーティーツールへのアクセスでは、アクセス認証情報を AWS Secrets Manager に保管し、インシデント対応者ロールにアクセス権を付与することをお勧めします。 最後に、インシデント対応 IAM ユーザーアカウントの管理は、 [Joiners、Movers、および Leavers プロセス](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) に追加し、定期的にテストして、意図されたアクセスのみが許可されていることを検証する必要があります。 ## リソース **関連するドキュメント:** + [Managing temporary elevated access to your AWS environment (AWS 環境へのアクセスの一時的な昇格の管理)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) + [AWS Security Incident Response Guide (AWS セキュリティインシデント対応ガイド) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) + [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) + [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) + [IAM ユーザー用のアカウントパスワードポリシーの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) + [AWS での多要素認証 (MFA) の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) + [ Configuring Cross-Account Access with MFA (MFA を使用したクロスアカウントアクセスの設定) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/) + [ Using IAM Access Analyzer to generate IAM policies (IAM Access Analyzer を使用した IAM ポリシーの設定) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/) + [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (マルチアカウント環境の AWS Organizations サービスコントロールポリシーのためのベストプラクティス) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) + [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (AWS アカウントのルートアクセスキーを使用した場合の通知の受信方法) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/) + [ Create fine-grained session permissions using IAM managed policies(AWS マネージドポリシーを使用して、きめ細かいセッション許可を作成する) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/) **関連動画:** + [AWS のインシデント対応とフォレンジックの自動化 ](https://www.youtube.com/watch?v=f_EcwmmXkXk) + [ランブック、インシデントレポート、インシデント対応の DIY ガイド](https://youtu.be/E1NaYN_fJUo) + [AWS 環境のセキュリティインシデントの準備と対応 ](https://www.youtube.com/watch?v=8uiO0Z5meCs) **関連サンプル:** + [ ラボ: AWS Account Setup and Root User (AWS アカウントのセットアップとルートユーザー) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/) + [ ラボ: Incident Response with AWS Console and CLI (AWS コンソールと CLI を使用したインシデント対応) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/) # SEC10-BP06 ツールを事前デプロイする 復旧までの調査時間を短縮できるように、セキュリティ担当者は適切なツールを AWS に事前にデプロイしておきます。 セキュリティエンジニアリングとオペレーションの機能を自動化するために、AWS の包括的な API とツールセットを使用できます。ID 管理、ネットワークセキュリティ、データ保護、モニタリング機能を完全に自動化し、すでに導入されている一般的なソフトウェア開発方法を使用して提供できます。セキュリティオートメーションを構築すれば、担当者がセキュリティ上の位置づけを監視し、イベントに手動で応答する代わりに、システムが監視、レビューを行い応答を開始できます。AWS サービス間で検索可能で関連性の高いログデータをインシデント対応者に自動的に提供する効果的な方法は、次を有効にすることです: [Amazon Detective](https://aws.amazon.com/detective/). インシデント対応チームが同じ方法でアラートに対応し続けると、アラート疲れになるリスクがあります。時間の経過とともに、チームはアラートに対する感度が鈍くなり、通常の状況の処理で間違いを犯したり、異常なアラートを見逃したりする可能性があります。自動化を利用すれば、繰り返し発生する通常のアラートを処理する機能を使用してアラート疲れを回避し、機密性の高いインシデントや独自のインシデントの処理を人間に任せることができます。Amazon GuardDuty, AWS CloudTrail Insights、および Amazon CloudWatch Anomaly Detection などの異常の検出システムを統合することで、よくあるしきい値ベースのアラートの負担を減らすことができます。 プロセス内のステップをプログラムで自動化すれば、手動プロセスを改善できます。イベントに対する修復パターンを定義したら、そのパターンを実行可能なロジックに分解して、そのロジックを実行するコードを記述できます。その後、対応者は、そのコードを実行して問題を修正します。時間の経過とともに、より多くのステップを自動化し、最終的には一般的なインシデントのクラス全体を自動的に処理できるようになります。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのオペレーティングシステム内で実行されるツールでは、AWS Systems Manager Run Command の使用を評価する必要があります。このコマンドを使うと、Amazon EC2 インスタンスのオペレーティングシステムにインストールしたエージェントを使用して、インスタンスをリモートで安全に管理できます。その際、Systems Manager Agent (SSM Agent) が必要です。これは多くの Amazon マシンイメージ (AMI) にデフォルトでインストールされています。ただし、一度インスタンスが侵害されると、そのインスタンス上で実行されているツールやエージェントからの応答は信頼できる応答とみなされません。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + ツールを事前デプロイする: セキュリティ担当者がインシデント発生時に適切な対応ができるよう、AWS に適切なツールをあらかじめ配備しておきます。 + [ラボ : AWS マネジメントコンソール と CLI を使用したインシデント対応 ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html) + [ Jupyter を使用したインシデント対応プレイブック - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) + [AWS セキュリティオートメーション ](https://github.com/awslabs/aws-security-automation) + リソースのタグ付けを実施する: インシデント発生時にリソースを特定できるように、調査中のリソースのコードなどの情報をリソースにタグ付けします。 + [AWS のタグ付け戦略 ](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) ## リソース **関連するドキュメント:** + [AWS Incident Response Guide (AWS インシデント対応ガイド) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) **関連動画:** + [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://youtu.be/E1NaYN_fJUo) # SEC10-BP07 ゲームデーを実施する ゲームデーは、シミュレーションや演習とも呼ばれ、現実的なシナリオでインシデント管理計画や手順を練習するための体系的な機会を提供する内部イベントです。これらのイベントは、実際のシナリオで使用されるのと同じツールやテクニックを使って、レスポンダーを訓練するものでなければなりません。ゲームデーは基本的に、準備をすることで対応能力を反復的に高めていくものです。ゲームデーのアクティビティを実行すべき理由は、次のとおりです。 + 準備態勢を検証する + 自信の向上 - シミュレーションやトレーニングスタッフから学ぶ + コンプライアンスまたは契約上の義務に準拠する + 認定のためのアーティファクトを生成する + 俊敏性 - 段階的な改善 + 高速化とツールの改善 + コミュニケーションとエスカレーションを詳細化する + まれで予期外の事態に備える このような理由から、シミュレーションアクティビティへの参加は、ストレスの多いイベント時の組織の有効性を高めるという価値があります。現実的で有益なシミュレーションアクティビティを開発するのは簡単な作業ではありません。すでに把握しているイベントを処理する手順や自動化のテストには一定のメリットがありますが、予想外の事象に対して自身をテストして継続的に改善するクリエイティブな [セキュリティインシデント対応のシミュレーション (SIRS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) アクティビティへの参加も重要です。 環境、チーム、ツールに合わせたカスタムのシミュレーションを作成します。問題を見つけて、それに関するシミュレーションを設計します。これは、漏洩した認証情報、不要なシステムと通信しているサーバー、または不正な露出をもたらす設定ミスなどが考えられます。組織に精通したエンジニアを特定して、シナリオと参加する別のグループを作成してもらいます。シナリオは現実的で、十分に価値のある挑戦的なものであるべきです。ロギング、通知、エスカレーション、ランブックまたは自動化の実行を実践する機会も含まれているはずです。シミュレーション中、レスポンダーは技術的および組織的スキルを発揮し、リーダーはインシデント管理スキルを高めるために参加する必要があります。シミュレーションの終わりには、チームの努力を称え、さらなるシミュレーションの反復、繰り返し、拡張の方法を探します。 [AWS は、インシデント対応ランブックのテンプレートを作成しました。](https://github.com/aws-samples/aws-incident-response-playbooks) これは、対応策の準備だけでなく、シミュレーションのベースとしても活用できます。計画時、シミュレーションは 5 段階に分けられます。 **証拠の収集: **この段階では、内部チケッティングシステム、モニタリングツールからのアラート、匿名のヒント、または公共のニュースなどさまざまな手法を使ってアラートを取得します。次にチームはインフラストラクチャとアプリケーションログのレビューを開始して、侵害のソースを特定します。このステップでは、内部エスカレーションとインシデントリーダーシップも関与する必要があります。特定されたら、チームがインシデントの封じ込めに取り掛かります。 **インシデントを封じ込める: **チームはインシデント発生を特定し、侵害のソースを突き止めます。チームは次に、侵害された認証情報の無効化、コンピューティングリソースの隔離、またはロールのアクセス許可の取り消しなど、封じ込めるためのアクションを取る必要があります。 **インシデントを根絶する **これでインシデントが封じ込められたため、チームは侵害を受けやすいアプリケーションやインフラストラクチャ設定の脆弱性を軽減する作業に取り掛かります。これには、ワークロードに使用された認証情報のローテーション、アクセスコントロールリスト (ACL) の修正、またはネットワーク設定の変更などが含まれます。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 実行 [本番環境で実行する](https://wa.aws.amazon.com/wat.concept.gameday.en.html): 主なスタッフやマネジメントが関与するさまざまな脅威に対してシミュレーションされた [インシデント](https://wa.aws.amazon.com/wat.concept.incident.en.html) 対応 [イベントを](https://wa.aws.amazon.com/wat.concept.event.en.html) 実行します (ゲームデー)。 + 教訓を把握する:  [本番環境で実行する](https://wa.aws.amazon.com/wat.concept.gameday.en.html) から得た教訓は、プロセスを改善するためのフィードバックループの一部であるべきです。 ## リソース **関連するドキュメント:** + [AWS Incident Response Guide (AWS インシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) + [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) **関連動画:** + [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://youtu.be/E1NaYN_fJUo)