# セキュリティ基盤
**Topics**
+ [
# SEC 1. ワークロードを安全に運用するにはどうすればよいですか。
](sec-01.md)
# SEC 1. ワークロードを安全に運用するにはどうすればよいですか。
ワークロードを安全に運用するためには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。「運用上の優秀性」で定義された要件とプロセスを組織やワークロードのレベルで作成し、あらゆる領域に適用します。AWS や業界の推奨事項と脅威インテリジェンスを最新の状態に保つことで、脅威モデルを進化させ、目標を制御できます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティオペレーションをスケールできます。
**Topics**
+ [
# SEC01-BP01 アカウントを使用してワークロードを分ける
](sec_securely_operate_multi_accounts.md)
+ [
# SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
](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_reduce_management_scope.md)
+ [
# SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する
](sec_securely_operate_automate_security_controls.md)
+ [
# SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける
](sec_securely_operate_threat_model.md)
+ [
# SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する
](sec_securely_operate_implement_services_features.md)
# SEC01-BP01 アカウントを使用してワークロードを分ける
マルチアカウント戦略を取り、環境 (本番稼働、開発、テストなど) とワークロードの間に共通ガードレールを構成し、分離を確立します。アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。
**期待される成果:** クラウドオペレーション、関連しないワークロード、環境を別々のアカウントに分離し、クラウドインフラストラクチャ全体のセキュリティを強化するアカウント構造。
**一般的なアンチパターン:**
+ データ重要度レベルの異なる複数の無関係のワークロードを同一アカウントに配置する。
+ きちんと定義されていない組織単位 (OU) 構造。
**このベストプラクティスを活用するメリット:**
+ 誤ってワークロードにアクセスした場合の影響範囲を軽減。
+ AWS サービス、リソース、およびリージョンへのアクセスの一元的ガバナンス。
+ ポリシーとセキュリティサービスの一元管理により、クラウドインフラストラクチャのセキュリティを維持する。
+ アカウント作成とメンテナンスプロセスの自動化。
+ コンプライアンスや規制要件に対応した、インフラストラクチャの集中監査。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS アカウントは、さまざまなデータ重要度レベルで稼働するワークロードまたはリソース間にセキュリティ分離境界を提供します。AWS は、マルチアカウント戦略を通して大規模にクラウドワークロードを管理し、この分離境界を活用するためのツールを提供します。AWS でのマルチアカウント戦略の概念、パターン、実装に関するガイダンスについては、「[複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」を参照してください。
一元管理下に複数の AWS アカウントがある場合、アカウントを組織単位 (OU) の層によって定義された階層に組織化する必要があります。次に、OU とメンバーアカウントに対してセキュリティ管理を組織化して適用することにより、組織内のメンバーアカウントに対して一貫性のある予防的制御を確立できます。セキュリティ管理は継承されるため、OU 階層の下位レベルにあるメンバーアカウントに対するアクセス許可をフィルタリングすることができます。優れた設計では継承を利用して、各メンバーアカウントに対して望ましいセキュリティ管理を達成するのに必要なセキュリティポリシーの件数と複雑性を軽減します。
[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) と [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、AWS 環境でマルチアカウント構造を実装および管理するサービスです。AWS Organizations では、アカウントを OU の 1 つ以上のレイヤーで定義された階層に整理できます。各 OU には複数のメンバーアカウントが含まれます。[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) を使用すると、組織管理者はメンバーアカウントに対してきめ細かな予防的コントロールを確立できます。[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) を使用してメンバーアカウントに対してプロアクティブコントロールと検出コントロールを確立できます。多くの AWS サービスは [AWS Organizations と統合](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)して、委任された管理コントロールを提供し、組織内のすべてのメンバーアカウントでサービス固有のタスクを実行します。
AWS Organizations の上にレイヤー化される [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、[ランディングゾーン](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)を持つマルチアカウント AWS 環境のワンクリックのベストプラクティス設定を提供します。ランディングゾーンは、Control Tower によって確立されるマルチアカウント環境への入口です。Control Tower には、AWS Organizations よりもいくつかの[利点](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/)があります。アカウントガバナンスを改善する 3 つの利点には次のようなものがあります。
+ 組織に対して承認されたアカウントに自動適用される、統合された必須のセキュリティコントロール。
+ 所定の OU セットに対してオン/オフと切り替えられるオプションのコントロール。
+ [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) は、事前承認されたベースラインと設定オプションを含むアカウントを組織内に自動デプロイします。
**実装手順**
1. **組織単位構造の設計:** 適切に設計された組織単位構造により、サービスコントロールポリシーやその他のセキュリティコントロールの作成と維持に必要な管理負担が軽減されます。組織単位の構造は、[ビジネスニーズ、データ機密性、ワークロード構造と整合](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)させる必要があります。
1. **マルチアカウント環境のランディングゾーンを作成する:** ランディングゾーンは、組織がワークロードを迅速に開発、起動、デプロイできる一貫したセキュリティとインフラストラクチャの基盤を提供します。[カスタム構築のランディングゾーンまたは AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html) を使用して、環境をオーケストレーションできます。
1. **ガードレールの確立:** ランディングゾーンを通して環境に一貫したセキュリティガードレールを実装します。AWS Control Tower には、デプロイできる一連の[必須](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html)および[オプション](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html)のコントロールが用意されています。必須コントロールは、Control Tower 実装時に自動的にデプロイされます。強く推奨されたコントロールとオプションのコントロールのリストを確認し、ニーズに適したコントロールを実装します。
1. **新しく追加されたリージョンへのアクセスを制限する**: 新しい AWS リージョンについて、ユーザーやロールなどの IAM リソースは、有効にしたリージョンのみに伝播されます。このアクションは、[Control Tower を使用する場合はコンソールから](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html)、または [AWS Organizations](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/) の IAM アクセス権限ポリシーを調整することで実行できます。
1. **AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) を検討する**: StackSets を使用すると、IAM ポリシー、ロール、グループなどのリソースをさまざまな AWS アカウントとリージョンに承認されたテンプレートからデプロイできます。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](sec_identities_identity_provider.md)
**関連ドキュメント:**
+ [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)
+ [CloudFormation StackSets を利用した複数の AWS アカウントやリージョンを横断したリソース展開](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/)
+ [Organizations に関するよくある質問](https://aws.amazon.com/organizations/faqs/)
+ [AWS Organizations の用語と概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
+ [マルチアカウント環境における AWS Organizations サービスコントロールポリシーのベストプラクティス](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [AWS アカウント管理リファレンスガイド](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html)
+ [複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
**関連動画:**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [AWS Control Tower を使用した複数アカウントのビルドと管理](https://www.youtube.com/watch?v=agpyuvRv5oo)
+ [既存の組織で Control Tower を有効にする](https://www.youtube.com/watch?v=CwRy0t8nfgM)
# SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
ルートユーザーは AWS アカウントで最も権限が高いユーザーであり、アカウント内の全リソースに対する完全な管理者アクセスがあるだけでなく、場合によってはセキュリティポリシーによる制限の対象外となります。ルートユーザーへのプログラムによるアクセスを無効化し、ルートユーザーに対する適切なコントロールを確立し、さらにルートユーザーの定期的使用を避けることにより、ルート認証情報を不用意に曝露するリスク、それによるクラウド環境の侵害を軽減することができます。
**期待される成果:** ルートユーザーのセキュリティを保護することで、ルートユーザーの認証情報が不正利用された場合に付帯的または意図的な損害が発生する可能性を抑えることができます。検出コントロールを確立することによっても、ルートユーザーを使ったアクションが取られると適切な担当者にアラートを送信できます。
**一般的なアンチパターン:**
+ ルートユーザー認証情報を必要とする少数以外のタスクに対してもルートユーザーを使用する。
+ 緊急時に重要なインフラストラクチャ、プロセス、担当者が正常に機能するかどうかを検証するために、定期的な緊急時対応計画のテストを怠っている。
+ 典型的なアカウントログインフローのみを考慮し、代替アカウント回復方法を考慮することも、テストすることもしていない。
+ DNS、E メールサーバー、および携帯電話会社がアカウント復旧フローで使用されるにもかからず、重要なセキュリティ境界の一部として対処していない。
**このベストプラクティスを活用するメリット:** ルートユーザーへのアクセスを確保することで、アカウントで行われるアクションは制御され監査されているという安心感が得られます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS は、アカウントを保護するのに役立つ多くのツールを提供しています。ただし、これらの対策の一部は既定では有効になっていないため、実装するには直接的な措置を講じる必要があります。これらの推奨事項を、AWS アカウントをセキュリティ保護するための基本的なステップと考えてください。これらのステップを実装する際、セキュリティ管理を継続的に評価およびモニタリングすることが重要となります。
AWS アカウントを初めて作成する際は、アカウント内のすべての AWS のサービスとリソースに完全なアクセス許可を持つ 1 つの ID から始めます。この ID は、AWS アカウントのルートユーザーと呼ばれます。アカウントの作成に使用したメールアドレスとパスワードを使用して、ルートユーザーとしてサインインできます。AWS ルートユーザーに付与されるアクセス権が昇格しているため、[特にそれが必要となる](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)タスクを実行する AWS ルートユーザーの使用は、制限する必要があります。ルートユーザーのログイン認証情報は厳重に保護し、AWS アカウントルートユーザーには必ず多要素認証 (MFA) を使用します。
ユーザー名、パスワード、多要素認証 (MFA) デバイスを使用してルートユーザーにログインする通常の認証フローに加えて、アカウントに関連付けられた E メールアドレスと電話番号にアクセスし、AWS アカウントルートユーザーにログインするためのアカウント復旧フローもあります。そのため、復旧メールを送信するルートユーザーの E メールアカウントと、そのアカウントに関連する電話番号をセキュリティ保護することも同程度に重要となります。また、ルートユーザーに関連付けられた E メールアドレスが、同じ AWS アカウントの E メールサーバーやドメインネームサービス (DNS) リソースでホストされている場合、潜在的な循環依存性についても考慮する必要があります。
AWS Organizations を使用する場合、それぞれにルートユーザーが含まれる AWS アカウントが複数あります。1 つのアカウントを管理アカウントに指定し、その管理アカウントの下に何層ものメンバーアカウントを追加することができます。管理アカウントのルートユーザーのセキュリティ保護を優先してから、メンバーアカウントのルートユーザーに対処してください。管理アカウントのルートユーザーをセキュリティ保護する戦略は、メンバーアカウントのルートユーザーとは異なり、メンバーアカウントのルートユーザーに対しては予防的なセキュリティコントロールを講じることができます。
**実装手順**
ルートユーザーのコントロールを確立するには、次の実装ステップが推奨されます。該当する場合、推奨事項は [CIS AWS Foundations benchmark version 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html) に対応します。AWS アカウントとリソースのセキュリティを保護するときは、これらのステップに加えて、[AWS のベストプラクティスのガイドライン](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)も参照してください。
**予防的コントロール**
1. アカウントの正確な[連絡先情報](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)を設定します。
1. この情報は、紛失したパスワードの復旧フロー、紛失した MFA デバイスアカウントの復旧フロー、およびチームとの重要なセキュリティ関連のコミュニケーションに使用されます。
1. 企業ドメインによってホストされた E メールアドレスを使用します (ルートユーザーの E メールアドレスとしては、できれば配布リストのほうが望ましい)。個人の E メールアカウントではなく配布リストを使うことにより、長期的にはルートアカウントへのアクセスに対して冗長性と継続性を追加することになります。
1. 連絡先情報に記載された電話番号は、この目的専用の安全なものである必要があります。この電話番号をどこかに記載したり、誰かと共有したりしないでください。
1. ルートユーザーにはアクセスキーを作成しないでください。アクセスキーが存在する場合は、それを削除します (CIS 1.4)。
1. ルートユーザーに対する長期保存可能なプログラム認証情報 (アクセスキーとシークレットキー) は排除します。
1. ルートユーザーのアクセスキーが既にある場合は、そのキーを使用するプロセスを移行させて、AWS Identity and Access Management (IAM) ロールの一時的なアクセスキーを使用した後、[ルートユーザーのアクセスキーを削除する](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key)必要があります。
1. ルートユーザーの認証情報を保管する必要があるかどうかを決定します。
1. AWS Organizations を使用して新しいアカウントを作成している場合、新規メンバーアカウントのルートユーザーの初期パスワードはランダムな値に設定され、決して公開されることはありません。必要に応じて[メンバーアカウントへのアクセス権を取得する](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root)ときは、AWS Organization 管理アカウントのパスワードリセットフローを使用することを検討します。
1. スタンドアロン AWS アカウントまたは管理 AWS Organization アカウントに対しては、ルートユーザーの認証情報を作成して安全に保管することを検討してください。ルートユーザーに MFA を使用します。
1. AWS マルチアカウント環境のメンバーアカウントのルートユーザーには、予防的コントロールを使用します。
1. メンバーアカウントには、[ルートユーザー向けのルートアクセスキーの作成を拒否する](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys)予防的ガードレールの使用を検討します。
1. メンバーアカウントには、[ルートユーザーとしてのアクションを拒否する](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions)予防的ガードレールの使用を検討します。
1. ルートユーザーの認証情報が必要な場合:
1. 複雑なパスワードを使用します。
1. ルートユーザー、特に AWS Organizations 管理 (支払者) アカウント (CIS 1.5) に対しては多要素認証 (MFA) を有効化します。
1. 回復力とセキュリティのために、ハードウェア MFA デバイスを検討してください。これは、単回使用デバイスを使用することにより、MFA コードを含むデバイスが他の目的に再使用される可能性が少なくなるためです。電池式のハードウェア MFA デバイスが定期的に交換されていることを検証してください。(CIS 1.6)
+ ルートユーザーに対して MFA を設定するときは、[仮想 MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) または[ハードウェア MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root) デバイスのいずれかを作成する手順に従います。
1. バックアップ用に複数の MFA デバイスを登録することを検討します。[MFA デバイスは 1 アカウントにつき 8 台まで登録できます](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/)。
+ ルートユーザーに対して複数の MFA デバイスを登録すると、[MFA デバイス紛失時にアカウントを復旧するフロー](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/)が自動的に無効になります。
1. パスワードは安全に保管し、電子的にパスワードを保管する際は循環依存関係を検討してください。入手するために同じ AWS アカウントへのアクセスが必要となる方法でパスワードを保管しないでください。
1. オプション: ルートユーザーに対して定期的なパスワードローテーションスケジュールを設定することを検討します。
+ 認証情報管理のベストプラクティスは、規制およびポリシー要件によって異なります。MFA によって保護されるルートユーザーは、認証の単一要素としてパスワードに依存しません。
+ [ルートユーザーのパスワードを定期的に変更](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_change-root.html)することで、意図せず漏洩したパスワードが不正利用されるリスクを減らせます。
「**発見的コントロール**」
+ ルート認証情報の使用を検出するアラームを作成します (CIS 1.7)。[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) を使用すると、[RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) の検出結果を使ってルートユーザー API 認証情報の使用状況をモニタリングしたり、アラートを発したりすることができます。
+ [AWS Config 用の AWS Well-Architected セキュリティの柱コンフォーマンスパック](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html)に含まれる検出管理を、評価し実装します。AWS Control Tower を使用している場合は、Control Tower 内で提供されている[強く推奨されるコントロール](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html)を評価し実装します。
**運用ガイダンス**
+ 組織で、ルートユーザー認証情報へのアクセスが必要な担当者を決定します。
+ 1 人の担当者がすべての必要な認証情報とルートユーザーアクセスを取得するために MFA にアクセスするのを回避するため、2 人制を採用します。
+ アカウントに関連付けられた電話番号と E メールエイリアス (パスワードリセットと MFA リセットフローに使用される) は、個人ではなく、組織が管理するよう徹底してください。
+ ルートユーザーは例外的にのみ使用します (CIS 1.7)。
+ AWS のルートユーザーを、たとえ運営業務であっても日常的なタスクに使用してはなりません。[ルートユーザーを必要とする AWS タスク](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)を実行するときは、必ずルートユーザーとしてログインします。その他すべてのアクションは、適切なロールを持つ他のユーザーが実行しなければなりません。
+ ルートユーザーにアクセスできることを定期的にチェックし、ルートユーザー認証情報を使用する必要がある緊急事態の前に手順をテストしておきます。
+ アカウントに関連付けられている E メールアドレスと[代理連絡先](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)に記載されている E メールアドレスが有効であることを定期的にチェックします。これらの E メールの受信箱に、セキュリティに関する通知が abuse@amazon.com から届いていないか監視します。また、アカウントに関連付けられた電話番号があれば、それが通じることも確認してください。
+ ルートアカウントの不正使用に対処するインシデント対応手順を準備しておきます。AWS アカウントに対するインシデント対応戦略策定に関する詳細は、「[AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)」と、ホワイトペーパー「セキュリティの柱」の「[インシデント対応](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)」セクションにあるベストプラクティスを参照してください。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP01 アカウントを使用してワークロードを分ける](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 強力なサインインメカニズムを使用する](sec_identities_enforce_mechanisms.md)
+ [SEC03-BP02 最小特権のアクセスを付与します](sec_permissions_least_privileges.md)
+ [SEC03-BP03 緊急アクセスのプロセスを確立する](sec_permissions_emergency_process.md)
+ [SEC10-BP05 アクセスを事前プロビジョニングする](sec_incident_response_pre_provision_access.md)
**関連ドキュメント:**
+ [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)
+ [Amazon GuardDuty – root credential usage alert](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage)
+ [CloudTrail を使用してルート認証情報の使用状況をモニタリングするためのステップバイステップガイド](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-20)
+ [AWS での使用が承認された MFA トークン](https://aws.amazon.com/iam/features/mfa/)
+ AWS に [Break Glass アクセス](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)を実装する
+ [AWS アカウントのセキュリティを改善するための 10 個の項目](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/)
+ [自分の AWS アカウントで不正なアクティビティに気づいた場合はどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/)
**関連動画:**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Limiting use of AWS root credentials](https://youtu.be/SMjvtxXOXdU?t=979) from AWS re:inforce 2022 – Security best practices with AWS IAM
# SEC01-BP03 管理目標を特定および検証する:
脅威モデルから特定されたコンプライアンス要件とリスクに基づいて、ワークロードに適用する必要がある管理目標および管理を導き出し、検証します。管理目標と制御を継続的に検証することは、リスク軽減の効果測定に役立ちます。
**期待される成果:** ビジネスのセキュリティコントロール上の目標が、コンプライアンス要件に一致するように明確に定義されます。自動化とポリシーを通じて統制が実装および実施され、目標を達成するために有効かどうかが継続的に評価されています。ある時点および一定期間の双方における有効性を示す証拠を、監査担当者にすぐに報告可能です。
**一般的なアンチパターン:**
+ セキュリティを保証するために守るべき規制要件、市場の期待、業界標準についての理解が、ビジネスにとって不十分である
+ サイバーセキュリティフレームワークと統制目標が、ビジネスの要件とかみ合っていない
+ 実施されている統制が、測定可能な方法で統制目標にしっかりと適合していない
+ 統制の有効性の報告に自動化を使っていない
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
セキュリティ統制目標の基礎として活用できる、一般的なサイバーセキュリティフレームワークは多数あります。ビジネスの規制要件、市場の期待、業界標準を考慮し、どのフレームワークがニーズに最も適しているかを判断してください。例えば、[AICPA SOC 2](https://aws.amazon.com/compliance/soc-faqs/)、[HITRUST](https://aws.amazon.com/compliance/hitrust/)、[PCI-DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)、[ISO 27001](https://aws.amazon.com/compliance/iso-27001-faqs/)、[NIST SP 800-53](https://aws.amazon.com/compliance/nist/) などがあります。
特定した統制目標について、利用する AWS サービスがそれらの目標の達成にどのように役立つかを理解してください。目標とするフレームワークに沿ったドキュメントやレポートを探すときは [AWS Artifact](https://aws.amazon.com/artifact/) を使用します。これらの文書には、AWSが引き受ける責任の範囲と、顧客が引き受けるそれ以外の範囲についてのガイダンスが記されています。さまざまなフレームワークのコントロールステートメントに沿った、サービス固有のガイダンスの詳細については、「[AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)」を参照してください。
目標達成を目指して統制を定義する際は、予防的統制を用いて実施について明文化し、発見的統制を用いて緩和策を自動化します。[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を使用すると、AWS Organizations 全体で非準拠のリソース構成やアクションを予防することができます。非準拠のリソースを監視および報告するときは [AWS Config](https://aws.amazon.com/config/) にルールを適用し、動作を確認できたらルールを強制モデルに切り替えます。自社のサイバーセキュリティのフレームワークに合わせて、事前定義されたマネージドルール一式を導入するときは、最初の選択肢として [AWS Security Hub CSPM の標準](https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html)の使用を検討します。AWS Foundational Service Best Practices (FSBP) 標準と CIS AWS Foundations Benchmark は、複数の標準フレームワークに共通の多数の目標に沿った統制を実現できるため、出発点として優れています。Security Hub CSPM に希望する統制検出の機能が組み込まれていない場合は、[AWS Config コンフォーマンスパック](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)で補完できます。
AWS Global Security and Compliance Acceleration (GSCA) チームが推奨する [APN パートナーバンドル](https://aws.amazon.com/partners/programs/gsca/bundles/)を使用すると、セキュリティアドバイザー、コンサルティング機関、証拠収集および報告のシステム、監査人、その他補完サービスによる支援を必要に応じて利用できます。
### 実装手順
1. 一般的なサイバーセキュリティフレームワークを評価し、選択したフレームワークに合わせて統制目標を定めます。
1. AWS Artifact を使用して、フレームワークのガイダンスと責任に関する関連文書を入手します。責任共有モデルにおいて、コンプライアンスのどの部分が AWS 側の責任で、どの部分が貴社の責任であるかを理解します。
1. SCP、リソースポリシー、ロール信頼ポリシー、その他のガードレールを使用して、非準拠のリソース構成やアクションを防止します。
1. 自社の統制目標に沿った Security Hub CSPM の標準と AWS Config コンフォーマンスパックの導入を評価します。
## リソース
**関連するベストプラクティス:**
+ [SEC03-BP01 アクセス要件を定義する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_define.html)
+ [SEC04-BP01 サービスとアプリケーションのログ記録を設定する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_app_service_logging.html)
+ [SEC07-BP01 データ分類スキームを理解する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_identify_data.html)
+ [OPS01-BP03 ガバナンス要件を評価する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_governance_reqs.html)
+ [OPS01-BP04 コンプライアンス要件を評価する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_compliance_reqs.html)
+ [PERF01-BP05 ポリシーとリファレンスアーキテクチャを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_use_policies_and_reference_architectures.html)
+ [COST02-BP01 組織の要件に基づいてポリシーを策定する](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html)
**関連ドキュメント:**
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**関連ツール:**
+ [AWS Artifact](https://aws.amazon.com/artifact/)
# SEC01-BP04 セキュリティの脅威と推奨事項の最新情報を入手する
業界の脅威インテリジェンスの公開情報やデータフィードが更新されていないか監視して、脅威や緩和策の最新情報を常に把握します。最新の脅威データに基づいて自動更新されるマネージドサービスを評価してください。
**期待される成果:** 業界で最新の脅威や推奨事項が公表されると同時にそれらを把握できます。 自動化を活用して、新たな脅威を特定した時点で、潜在的な脆弱性やエクスポージャを検出します。これらの脅威に対して緩和措置を講じます。 最新の脅威インテリジェンスで自動的に更新される AWS サービスを採用します。
**一般的なアンチパターン:**
+ 最新の脅威インテリジェンスを常に把握するための、信頼性と再現性が高いメカニズムがない。
+ テクノロジーポートフォリオ、ワークロード、依存関係の手動インベントリを保持していて、潜在的な脆弱性やエクスポージャについて人間がレビューする必要がある。
+ ワークロードと依存関係を、既知の脅威に対する緩和策が盛り込まれた最新バージョンに更新するメカニズムが導入されていない。
**このベストプラクティスを活用するメリット:** 脅威インテリジェンスの情報源から最新の情報を入手することで、脅威の分野における重要な変化を見落としてビジネスに影響を及ぼすリスクを避けることができます。 ワークロードやその依存関係をスキャンして、脆弱性やエクスポージャが潜んでいる箇所を検出および修正するための自動化体制が整い、手動での代替手段と比較して、リスクを迅速かつ予測どおりに軽減できます。 これにより、脆弱性の緩和に関連する時間やコストを抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
信頼できる脅威インテリジェンスの公開情報を確認して、脅威の状況を常に把握してください。 既に周知の脅威への対抗手段、テクニック、手順 (TTP) に関するドキュメントは、[MITRE ATT&CK](https://attack.mitre.org/) のナレッジベースでご覧いただけます。MITRE の「[Common Vulnerabilities and Exposures (CVE)](https://cve.org/)」 リストでは、ご利用の製品に関する既知の脆弱性情報を入手できます。Open Worldwide Application Security Project (OWASP) の中でも人気の高い [OWASP Top 10](https://owasp.org/www-project-top-ten/) プロジェクトでは、ウェブアプリケーションの重大なリスクを把握できます。
AWS のセキュリティイベントと推奨される修復手順に関する最新情報は、CVE の AWS [セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)で入手できます。
最新情報を入手するための負担やオーバーヘッドを全体的に減らすために、新しい脅威インテリジェンスを自動で随時取り込む AWS サービスの使用を検討してください。 例えば、[Amazon GuardDuty](https://aws.amazon.com/guardduty/) は業界の脅威インテリジェンスの最新情報を常に把握し、アカウント内の異常動作や脅威の兆候の検出に役立てています。 [Amazon Inspector](https://aws.amazon.com/inspector/) は、継続スキャンに使用している CVE のデータベースを自動更新しています。 [AWS WAF](https://aws.amazon.com/waf/) と [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) はどちらも、新しい脅威が登場すると自動的に更新されるマネージドルールグループを利用しています。
フリートの自動管理とパッチ適用については、「[運用上の優秀性の柱 – AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)」を参照してください。
## 実装手順
+ ビジネスや業界に関連する脅威インテリジェンスの最新公開情報を購読します。AWS セキュリティ速報を購読します。
+ Amazon GuardDuty や Amazon Inspector など、新しい脅威インテリジェンスを自動的に組み込むサービスの採用を検討してください。
+ Well-Architected 運用上の優秀性の柱のベストプラクティスに沿って、フリート管理とパッチ適用の戦略をデプロイします。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_threat_model.html)
+ [OPS01-BP05 脅威の状況を評価する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_eval_threat_landscape.html)
+ [OPS11-BP01 継続的改善のプロセスを用意する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_evolve_ops_process_cont_imp.html)
# SEC01-BP05 セキュリティ管理のスコープを縮小する
特定の統制の管理を AWS に移行する AWS サービス (マネージドサービス) を利用することで、セキュリティの範囲を縮小できるか判断します。そうしたサービスを導入することで、インフラストラクチャのプロビジョニング、ソフトウェアのセットアップ、パッチ適用、バックアップなどのセキュリティメンテナンスのタスクを軽減できます。
**期待される成果:** ワークロードに適した AWS サービスを選ぶときに、セキュリティ管理の範囲を検討します。管理オーバーヘッドとメンテナンスタスクのコスト (総保有コスト (TCO)) が、Well-Architected の他の考慮事項に加えて、選択したサービスのコストと比較検討されます。統制の評価と検証の手順に、AWS の統制とコンプライアンスの文書が組み込まれています。
**一般的なアンチパターン:**
+ 選択したサービスの責任共有モデルをしっかりと理解しないまま、ワークロードをデプロイする。
+ データベースやその他のテクノロジーを、同等のマネージドサービスを評価することなく仮想マシンでホストする。
+ マネージドサービスオプションと比較する際に、仮想マシンでテクノロジーをホストする場合の総保有コスト (TCO) にセキュリティ管理タスクを考慮していない。
**このベストプラクティスを活用するメリット:** マネージドサービスを使用すると、運用上のセキュリティ統制を管理する全体的な負担を軽減でき、セキュリティリスクと総保有コストを減らすことができます。本来なら特定のセキュリティタスクに費やしていた時間を、ビジネスに付加価値をもたらすタスクに使うことができます。マネージドサービスを利用すれば、一部の統制要件を AWS に移し、コンプライアンス要件のスコープを縮小することもできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS では、多数の方法でワークロードのコンポーネントを統合できます。多くの場合、Amazon EC2 インスタンスにテクノロジーをインストールして実行するには、セキュリティの責任の大部分を自社で引き受けなければなりません。特定の統制の運用負担を軽減するには、責任共有モデルにおける自社の責任範囲が狭くなる AWS マネージドサービスを特定し、それらを既存のアーキテクチャでどのように使用できるかを理解してください。例えば、データベースのデプロイに [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) を使用する、コンテナのオーケストレーションに [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) または [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/) を使用する、もしくは[サーバーレスのオプション](https://aws.amazon.com/serverless/)を使用する、といったことが挙げられます。新しいアプリケーションを構築するときは、セキュリティ統制の実装と管理に関して、どのサービスが時間とコストの削減に役立つかを考えてください。
コンプライアンス要件も、サービス選択時の検討材料となり得ます。マネージドサービスでは、一部の要件のコンプライアンスを AWS に移すことができます。サービスの自社で運用管理する側面の監査や、関連する AWS 監査報告書の統制に関するステートメントの受け入れがどの程度容易かをコンプライアンスチームと話し合ってください。[AWS Artifact](https://aws.amazon.com/artifact/) で検出した監査アーティファクトは、AWS セキュリティ統制の証拠として監査人または規制当局に提出することができます。また、AWS の監査アーティファクトの一部によって提供された責任ガイダンスを、「[AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)」と併せて使用することで、アーキテクチャを設計することもできます。このガイダンスは、システムの特定のユースケースをサポートするために導入すべき追加のセキュリティ統制を決定するうえで役立ちます。
マネージドサービスを使用するときは、リソースを新しいバージョンに更新するプロセス (Amazon RDS で管理されるデータベースのバージョンや、AWS Lambda 関数のプログラミング言語ランタイムの更新など) をよく理解しておきましょう。そうした操作はマネージドサービスで実行される場合もありますが、更新のタイミングを設定し、運用への影響を理解することは依然としてお客様の責任です。[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) のようなツールを使用すると、こうした更新を自社の環境全体で追跡し管理することができます。
### 実装手順
1. マネージドサービスで置き換え可能なワークロードのコンポーネントを評価します。
1. ワークロードを AWS に移行する場合は、ワークロードのリホスト、リファクタリング、リプラットフォーム、再構築、または交換が必要かどうかを評価する際に、管理 (時間と費用) の削減とリスクの軽減を考慮してください。移行の開始時に追加投資を行うことで、長期的には大幅な節約になる場合があります。
1. 独自のテクノロジーデプロイをインストールして管理する代わりに、Amazon RDS などのマネージドサービスを導入することを検討します。
1. AWS Artifact の責任ガイダンスを参考にして、ワークロードに対して導入すべきセキュリティ統制を決定します。
1. 使用中のリソースのインベントリを保管し、新しいサービスやアプローチに関する最新情報を入手して、スコープを縮小する新たな機会を特定します。
## リソース
**関連するベストプラクティス:**
+ [PERF02-BP01 ワークロードに最適なコンピューティングオプションを選択する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_compute_hardware_select_best_compute_options.html)
+ [PERF03-BP01 データアクセスとストレージの要件に最適な専用データストアを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_data_use_purpose_built_data_store.html)
+ [SUS05-BP03 マネージドサービスを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_hardware_a4.html)
**関連ドキュメント:**
+ [Planned lifecycle events for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)
**関連ツール:**
+ [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Artifact](https://aws.amazon.com/artifact/)
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**関連動画:**
+ [How do I migrate to an Amazon RDS or Aurora MySQL DB instance using AWS DMS?](https://www.youtube.com/watch?v=vqgSdD5vkS0)
+ [AWS re:Invent 2023 - Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
# SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する
あらゆる AWS 環境で標準とするセキュリティ統制の開発とデプロイに際しては、最新の DevOps プラクティスを適用してください。 標準的なセキュリティ統制と構成を Infrastructure as Code (IaC) テンプレートに定義し、バージョン管理システムで変更を取り込み、CI/CD パイプラインの一環として変更をテストし、AWS 環境への変更のデプロイを自動化します。
**期待される成果:** IaC テンプレートで標準化されたセキュリティ統制が定義され、バージョン管理システムにコミットされます。 変更を検出し、テストと AWS 環境ヘのデプロイを自動化する CI/CD パイプラインが整備されています。 ガードレールが効いていて、テンプレート内の設定ミスをデプロイ前に検出し、警告します。 標準の統制が効いている環境にワークロードがデプロイされます。 チームには、承認済みのサービス構成をセルフサービスメカニズムを通じてデプロイする権限が与えられています。 統制の構成、スクリプト、関連データに対して、安全なバックアップと復旧の戦略が実施されています。
**一般的なアンチパターン:**
+ 標準のセキュリティ統制に対する変更をウェブコンソールやコマンドラインインターフェイスを使用して手作業で行っている。
+ 中央のチームが定義した統制の実装は、個々のワークロードチームによる手作業に頼っている。
+ ワークロードチームの要求に応じてワークロードレベルの統制をデプロイするのは、中央のセキュリティチームに一任されている。
+ セキュリティ統制の自動化スクリプトの開発、テスト、デプロイを同じ個人またはチームが担当でき、職務分離やチェックアンドバランス (抑制と均衡) が適切に機能していない。
**このベストプラクティスを活用するメリット:** 標準のセキュリティ統制をテンプレートに定義しておくことで、バージョン管理システムを使って変化を経時的に追跡し、比較することができます。 変更のテストとデプロイを自動化することで、プロセスが標準化されて予測可能性が高まり、デプロイの成功率が上がり、繰り返しの手作業を省くことができます。 承認済みのサービスと構成をワークロードチームがデプロイできるセルフサービスのメカニズムが用意されているため、構成ミスや誤用のリスクが軽減されます。また、開発プロセスの早い段階で統制を組み込むことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
「[SEC01-BP01 アカウントを使用してワークロードを分ける](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html)」に記載のベストプラクティスに従うと、AWS Organizations を使って管理している異なる環境ごとに、複数の AWS アカウントアカウントを抱えることになります。 これらの環境やワークロードで個別のセキュリティ統制が必要になる場合がある一方で、一部のセキュリティ統制は標準化して組織全体に適用できます。 例えば、一元管理の ID プロバイダーの統合、ネットワークとファイアウォールの定義、ログの保管と分析のための標準の場所の設定などが該当します。 Infrastructure as Code (IaC) を使用すると、アプリケーションコードの開発と同等の厳格さをインフラストラクチャのプロビジョニングに適用できるように、IaC を使用すると、標準のセキュリティ統制を同様に定義してデプロイすることができます。
セキュリティ統制は、可能な限り宣言的な方法で定義し ([AWS CloudFormation](https://aws.amazon.com/cloudformation/) で定義する場合と同じ)、ソース管理システムに保存します。 DevOps のプラクティスを使用して、統制のデプロイを自動化してリリースの予測可能性を高め、[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) などのツールを使ってテストを自動化し、デプロイした統制の、目的とする構成からの逸脱を検出します。 CI/CD パイプラインの構築には、[AWS CodePipeline](https://aws.amazon.com/codepipeline/)、[AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodeDeploy](https://aws.amazon.com/codedeploy/) などのサービスを使用できます。これらのサービスを、他のデプロイパイプラインから分離された専用のアカウントで設定するときは、「[複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)」のガイダンスを考慮します。
テンプレートを定義して、AWS アカウント、サービス、構成の定義とデプロイを標準化することもできます。 この方法なら、それらの定義を中央のセキュリティチームが管理し、セルフサービスアプローチでワークロードチームに提供できます。 これを実現する方法の 1 つが [Service Catalog](https://aws.amazon.com/servicecatalog/) を使用した方法です。この方法では、ワークロードチームが独自のパイプラインデプロイに組み込みこむことのできる製品として、テンプレートをパブリッシュできます。 [AWS Control Tower](https://aws.amazon.com/controltower/) を使用している場合、出発点として使用できるテンプレートや統制がいくつか用意されています。 Control Tower には、ワークロードチームが、ユーザーが定義した標準を使って新しい AWS アカウントアカウントを作成できる、[Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/af-customization-page.html) という機能もあります。 新しいアカウントが必要だとワークロードチームが判断した際に、その承認と作成を中央のチームに依存する必要がなくなります。 これらのアカウントは、さまざまなワークロードコンポーネントを、それぞれの機能や動作、処理対象のデータの機密性といった理由で分離する場合に必要になることがあります。
## 実装手順
1. テンプレートをバージョン管理システムに保存し、管理する方法を決定します。
1. テンプレートをテストおよびデプロイする CI/CD パイプラインを作成します。 設定ミスがないかチェックし、テンプレートが会社の標準に準拠していることを確認するテストを定義します。
1. ワークロードチームが要件に従って AWS アカウントやサービスをデプロイできるように、標準化されたテンプレートのカタログを作成しておきます。
1. 統制の構成、スクリプト、関連データに対して、安全なバックアップと復旧の戦略を実装します。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP01 バージョン管理を使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_version_control.html)
+ [OPS05-BP04 構築およびデプロイ管理システムを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_build_mgmt_sys.html)
+ [REL08-BP05 オートメーションを使用して変更をデプロイする](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_automated_changemgmt.html)
+ [SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_dev_a2.html)
**関連ドキュメント:**
+ [複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)
**関連する例:**
+ [Automate account creation, and resource provisioning using Service Catalog, AWS Organizations, and AWS Lambda](https://aws.amazon.com/blogs/mt/automate-account-creation-and-resource-provisioning-using-aws-service-catalog-aws-organizations-and-aws-lambda/)
+ [Strengthen the DevOps pipeline and protect data with AWS Secrets Manager, AWS KMS, and AWS Certificate Manager](https://aws.amazon.com/blogs/security/strengthen-the-devops-pipeline-and-protect-data-with-aws-secrets-manager-aws-kms-and-aws-certificate-manager/)
**関連ツール:**
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [Landing Zone Accelerator on AWS](https://github.com/awslabs/landing-zone-accelerator-on-aws)
# SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける
脅威モデリングを実行し、ワークロードの潜在的脅威と関連付けられた緩和策を特定し、最新の状態を維持します。脅威に優先順位を付け、セキュリティコントロール緩和策を調整して防止、検出、対応を行います。ワークロードの内容、および進化するセキュリティ環境の状況に応じてセキュリティコントロールを保持および維持します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
**脅威モデリングとは?**
「脅威モデリングとは、価値あるものを保護する状況において、脅威とその緩和策を特定し、伝達して理解する取り組みをいう」。– [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
**なぜ脅威モデリングが必要なのか?**
システムは複雑であり、時代とともに次第に複雑かつ高性能となり、提供するビジネス価値は向上し、顧客満足度とエンゲージメントは強化されています。つまり、IT 設計を決定する際は、増え続けるユースケースの件数を考慮する必要があるということです。このような複雑で数が多いユースケースの組み合わせは、非構造化アプローチでは一般に脅威の検出と緩和に効果がありません。代わりに必要となるのは、システムに対する潜在的な脅威を列挙し、緩和策を考案し、その緩和策に優先順位をつけて、組織の限定的なリソースがシステム全体のセキュリティ体制の改善に最大の効果を発揮できるような体系的アプローチです。
脅威モデリングは、このような体系的アプローチを提供する設計となっており、その狙いは、ライフサイクルの後半と比較すると相対的にコストと労力が低い設計プロセスの早い段階で問題を発見し、対処することです。このアプローチは、業界の原則である[セキュリティ戦略「*シフトレフト*」](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview)と一致しています。最終的に脅威モデリングは組織のリスク管理プロセスと統合し、脅威駆動型アプローチを使用して、実装するコントロールの決定を促します。
**脅威モデリングを実行するタイミング**
ワークロードのライフサイクルにおけるできるだけ早い段階で脅威モデリングを開始することにより、より柔軟に特定した脅威への対策を実施できるようになります。ソフトウェアのバグと同様、脅威を特定するのが早いほど、その対策のコスト効率が向上します。脅威モデルはライブドキュメントであり、ワークロードの変化に応じて進化し続ける必要があります。大きな変化、脅威の状況における変化が生じた場合や、新たな機能またはサービスを採用した場合などを含む、経時的な脅威モデルを保持します。
### 実装手順
**脅威モデリングの実行方法**
脅威モデリングにはさまざまな実行方法があります。プログラミング言語と同様、それぞれに長所と短所があり、自分に最も適した方法を選択する必要があります。そのうちの 1 つが「[Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame)」から始める方法です。ここでは、自由形式の質問をたずねることで脅威モデリングに枠組みを与えます。
1. **現在取り組んでいることは何か。**
この質問の目的は、構築しているシステム、さらにはセキュリティに関連するシステムに関する詳細を理解してそれに合意するのを支援することです。この質問に答える最も一般的な方法は、モデルや図を作成することです。それにより、現在構築しているものを[データフロー図](https://en.wikipedia.org/wiki/Data-flow_diagram)などを使って視覚化することができます。システムに関する推測と重要な詳細を書き留めることも、対象範囲を定義するのに役立ちます。これにより、脅威モデルに取り組む担当者全員の目指す方向が合致し、対象範囲外のトピック (システムの古いバージョンなど) に脱線して時間を浪費する事態を回避できます。例えば、ウェブアプリケーションを構築している場合、ブラウザクライアントのオペレーティングシステムの信頼できるブートシーケンスをモデル化する脅威については、あまり時間をかける価値があるとは思えません。
1. **問題化する可能性があるものは何か?**
ここで、システムに対する脅威を特定します。脅威とは、望ましくない影響を生じさせ、システムのセキュリティに悪影響を及ぼす恐れのある、偶発的または意図的なアクションや事象を指します。どのような問題が起きるかをはっきりと理解していなければ、何も対策は打てません。
何が問題になるのかに関して、定型的なリストは存在しません。このリストを作成するには、チームのメンバーと脅威モデリングに[参加する関係者](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips)との全員による、ブレインストーミングとコラボレーションが必要となります。ブレインストーミングは、[STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)) など、脅威を特定するモデルを使用するとスムーズに行うことができます。STRIDE は、評価すべきさまざまなカテゴリ (なりすまし、改ざん、否認、情報漏洩、サービス妨害、権限昇格) を提案するものです。また、[OWASP Top 10](https://owasp.org/www-project-top-ten/)、[HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/)、組織独自の脅威カタログなど、既存のリストを見直して調査することもブレインストーミングの刺激となり役に立ちます。
1. **どのように対処すべきか?**
前の質問と同様、考えられる緩和策について定型的なリストはありません。このステップに対する入力項目は、特定された脅威、アクター、および前のステップからの改善点です。
セキュリティとコンプライアンスは、[AWS とユーザー間で共有される責任](https://aws.amazon.com/compliance/shared-responsibility-model/)です。「それをどうするのですか?」という質問を行うときは、「誰がその責任者なのか?」ということもたずねていると理解することが重要です。ユーザーと AWS との間の、責任のバランスを理解することにより、ユーザーのコントロール下にある脅威モデリングの範囲を理解することができます。こちらは通常、AWS サービスの設定オプションと、ユーザー独自のシステムごとの緩和策とを組み合わせたものになります。
共有責任の AWS の担当部分については、[AWS サービスが多くのコンプライアンスプログラムの対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)であることがわかるはずです。これらのプログラムは、セキュリティとクラウドのコンプライアンスを維持するためにAWS に配置された堅牢なコントロールを理解するのに役立ちます。これらのプログラムの監査レポートは、AWS の顧客は [AWS Artifact](https://aws.amazon.com/artifact/) からダウンロードできます。
どの AWS サービスを使用していても、必ずお客様の責任となる要素が存在し、これらの責任に合わせた緩和策を脅威モデルに組み込む必要があります。AWS サービス自体のセキュリティコントロール緩和のためには、例えば、Identity and Access Management (認証と承認)、データ保護 (静止時と転送時)、インフラストラクチャセキュリティ、ログ、モニタリングなどのドメインを含む、さまざまなドメイン全体にセキュリティコントロールの実装を検討することが推奨されます。各 AWS サービスのドキュメントにはそれぞれ[セキュリティに関する項目](https://docs.aws.amazon.com/security/)があり、緩和策として利用できるセキュリティコントロールについてのガイダンスが記されています。重要ですので、記述しているコードとコード依存関係を考慮し、それらの脅威に対応するために設定できるコントロールについて考えてください。こうしたコントロールには、[入力の検証](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)、[セッションの処理](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling)、[境界の処理](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)などが含まれます。多くの場合、脆弱性の大部分はカスタムコードで発生するため、この領域を注視してください。
1. **十分に優れた仕事をしたか?**
狙いは、チームと組織が脅威モデルの質と、脅威モデリングを行う際の時間的な速さを改善することです。これらの改善は、練習、学習、指導、レビューを組み合わせることで実現します。十分に理解して実践的な経験を積むには、お客様とお客様のチームメンバー全員が「[Threat modeling the right way for builders training course](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)」または[ワークショップ](https://catalog.workshops.aws/threatmodel/en-US)を受講することが推奨されます。さらに、組織のアプリケーション開発のライフサイクルに、脅威モデリングを組み込む方法について知りたい方は、AWS セキュリティブログの「[脅威モデリングのアプローチ方法](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)」を参照してください。
**Threat Composer**
脅威モデリングをサポートし実行を導くには、[Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) ツールの使用を検討します。このツールは、脅威モデリングの価値を実感できるまでにかかる時間を、短縮するためのツールです。このツールは、以下の用途で役立ちます。
+ 自然な非線形のワークフローに該当する、[Threat grammar](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar) に沿った有益な脅威のステートメントを記述する
+ 人間が読める脅威モデルを生成する
+ 機械可読な脅威モデルを生成して、脅威モデルをコードとして扱えるようにする
+ Insights Dashboard を使用して、品質や対象範囲を改善できる分野をすばやく特定する
詳細については、Threat Composer にアクセスした後、システムで定義された**Example Workspace** に切り替えます。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP03 管理目標を特定および検証する:](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 セキュリティの脅威と推奨事項の最新情報を入手する](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 セキュリティ管理のスコープを縮小する](sec_securely_operate_reduce_management_scope.md)
+ [SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する](sec_securely_operate_implement_services_features.md)
**関連ドキュメント:**
+ [脅威モデリングのアプローチ方法](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (AWS セキュリティブログ)
+ [ NIST: Guide to Data-Centric System Threat modeling ](https://csrc.nist.gov/publications/detail/sp/800-154/draft)
**関連動画:**
+ [AWS Summit ANZ 2021 - How to approach threat modeling ](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery](https://www.youtube.com/watch?v=DjNPihdWHeA)
**関連するトレーニング:**
+ [Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [Threat modeling the right way for builders – AWS Workshop](https://catalog.workshops.aws/threatmodel)
**関連ツール:**
+ [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer)
# SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する
ワークロードのセキュリティ体制を進化させるために役立つ、AWS および AWS パートナーのセキュリティサービスと機能を評価および実装します。
**期待される成果:** AWS や AWS パートナーがリリースした新しい機能やサービスについて知らせるための標準的な実践方法が確立されています。これらの新機能が、環境とワークロードに対する既存および新規の統制の設計にどのように影響するかを評価します。
**一般的なアンチパターン:**
+ 関連する新しい機能やサービスの情報を迅速に入手するために、AWS のブログや RSS フィードを購読していない
+ セキュリティサービスや機能に関するニュースや最新情報を二次情報源から入手している
+ 組織内の AWS ユーザーに、常に最新情報に触れるよう推奨していない
**このベストプラクティスを活用するメリット:** 新しいセキュリティサービスや機能を常に把握していれば、クラウド環境やワークロードへの統制の実装について、情報に基づいて決断を下せます。進化するセキュリティ環境や、新たに出現した脅威への対策として AWS サービスを活用する方法を把握するうえで、それらの情報源が役に立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
AWS では、新しいセキュリティサービスや機能について、複数のチャネルを通じてお客様にご案内しています。
+ [AWS の最新情報](https://aws.amazon.com/new)
+ [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/)
+ [AWS セキュリティブログ](https://aws.amazon.com/blogs/security/)
+ [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)
+ [AWS ドキュメントの概要](https://aws.amazon.com/documentation/)
Amazon Simple Notification Service (Amazon SNS) を使用して [AWS Daily Feature Updates](https://aws.amazon.com/blogs/aws/subscribe-to-aws-daily-feature-updates-via-amazon-sns/) トピックを購読し、最新情報の包括的なサマリーを確認できます。[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_sns.html) や [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-announcements.html) などの一部のセキュリティサービスは、独自の SNS トピックで各サービスに関する新しい標準、検出結果、その他の最新情報を配信しています。
また、毎年世界中で開催される[カンファレンス、イベント、ウェビナー](https://aws.amazon.com/events/)でも、新しいサービスや機能が発表され、詳しく説明されています。中でも注目すべきは、毎年恒例の [AWS re:Inforce](https://reinforce.awsevents.com/) セキュリティカンファレンスと、より一般的な [AWS re:Invent](https://reinvent.awsevents.com/) カンファレンスです。前述の AWS のニュースチャネルでは、これらのカンファレンスでセキュリティやその他のサービスに関して発表した内容を共有しています。また、YouTube の [AWS Events チャンネル](https://www.youtube.com/c/AWSEventsChannel)では、深く掘り下げて学ぶブレイクアウトセッションをオンラインでご視聴いただけます。
セキュリティサービスの最新情報や新しい推奨事項について、[AWS アカウントチーム](https://aws.amazon.com/startups/learn/meet-your-aws-account-team)にお問い合わせいただくこともできます。セールスサポートチーム直通の連絡先情報がお手元にない場合は、[セールスサポートフォーム](https://aws.amazon.com/contact-us/sales-support/)からお問い合わせください。同様に、[AWS エンタープライズサポート](https://aws.amazon.com/premiumsupport/plans/enterprise/)にご登録いただいている場合は、Technical Account Manager (TAM) が毎週最新情報をお知らせします。また、TAM との定期的なレビューミーティングを設定できます。
### 実装手順
1. お気に入りの RSS リーダーでさまざまなブログや速報を購読するか、「Daily Feature Updates」SNS トピックを購読します。
1. 新しい機能やサービスについて直に学ぶため、どの AWS イベントに参加すべきかを評価します。
1. セキュリティサービスや機能の更新について質問がある場合は、AWS アカウントチームとのミーティングを設定します。
1. エンタープライズサポートへの登録を検討します。登録すると、Technical Account Manager (TAM) に定期的に相談できます。
## リソース
**関連するベストプラクティス:**
+ [PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_understand_cloud_services_and_features.html)
+ [COST01-BP07 新しいサービスリリースに関する最新情報を把握しておく](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management_scheduled.html)