# セキュリティの基礎
<a name="a-sec-security"></a>

**Topics**
+ [SEC 1.ワークロードを安全に運用するには、どうすればよいですか?](sec-01.md)

# SEC 1.ワークロードを安全に運用するには、どうすればよいですか?
<a name="sec-01"></a>

 ワークロードを安全に運用するには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。組織レベルおよびワークロードレベルにおいて、「運用上の優秀性」で定義した要件とプロセスを抽出し、それらをすべての領域に適用します。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_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 アカウントを使用してワークロードを分ける:
<a name="sec_securely_operate_multi_accounts"></a>

 マルチアカウント戦略を取り、環境 (本番稼働、開発、テストなど) とワークロードの間に共通ガードレールを構成し、分離を確立します。アカウントレベルの分類は、セキュリティ、請求、アクセスのために強力な分離境界を提供するため、強く推奨されます。 

**期待される成果:** クラウドオペレーション、無関係のワークロード、環境を別々のアカウントに分類し、クラウドインフラストラクチャ全体のセキュリティを向上させるアカウント構造。

**一般的なアンチパターン:**
+  データ重要度レベルの異なる複数の無関係のワークロードを同一アカウントに配置する。
+  きちんと定義されていない組織単位 (OU) 構造。

**このベストプラクティスを活用するメリット:**
+  誤ってワークロードにアクセスした場合の影響範囲が抑えられます。
+  AWS サービス、リソース、およびリージョンへのアクセスの一元的ガバナンス。
+  ポリシーとセキュリティサービスの一元管理により、クラウドインフラストラクチャのセキュリティを維持する。
+  アカウント作成とメンテナンスプロセスの自動化。
+  コンプライアンスや規制要件に対応した、インフラストラクチャの集中監査。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>

 AWS アカウント は、さまざまなデータ重要度レベルで稼働するワークロードまたはリソース間にセキュリティ分離境界を提供します。AWS は、マルチアカウント戦略を通して大規模にクラウドワークロードを管理し、この分離境界を活用するためのツールを提供します。AWS でのマルチアカウント戦略のコンセプト、パターン、および実装に関するガイダンスについては、「[Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」 (複数のアカウントを使用した AWS 環境の組織化) を参照してください。 

 一元管理下に複数の 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 環境でこのマルチアカウント構造を実装および管理するのに使用できる 2 つのサービスです。AWS Organizations では、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) では、事前承認されたベースラインと組織内の構成オプションを含むアカウントを自動的にデプロイできます。 

## 実装手順
<a name="implementation-steps"></a>

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 で [IAM アクセス許可を調整することにより実行できます](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/)。 

1.  **AWS[CloudFormation StackSets を検討する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)**: StackSets を使用すると、IAM ポリシー、ロール、グループなどのリソースをさまざまな AWS アカウント とリージョンに承認されたテンプレートからデプロイしやすくなります。 

## リソース
<a name="resources"></a>

**関連するベストプラクティス:** 
+ [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//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/) 
+  [組織関連の FAQ](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) 

**関連動画:** 
+  [自動化とガバナンスにより AWS の大規模な採用を可能にする](https://youtu.be/GUMSgdB-l6s) 
+  [Well-Architected の手法によるセキュリティのベストプラクティス](https://youtu.be/u6BCVkXkPnM) 
+  [AWS Control Tower を使って複数のアカウントをビルドおよび統制する](https://www.youtube.com/watch?v=agpyuvRv5oo) 
+  [既存の組織に対して Control Tower を有効化する](https://www.youtube.com/watch?v=CwRy0t8nfgM) 

**関連ワークショップ:** 
+  [Control Tower Immersion Day](https://controltower.aws-management.tools/immersionday/) 

# SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
<a name="sec_securely_operate_aws_account"></a>

 ルートユーザーは AWS アカウント で最も権限が高いユーザーであり、アカウント内の全リソースに対する完全な管理者アクセスがあるだけでなく、場合によってはセキュリティポリシーによる制限の対象外となります。ルートユーザーへのプログラムによるアクセスを無効化し、ルートユーザーに対する適切なコントロールを確立し、さらにルートユーザーの定期的使用を避けることにより、ルート認証情報を不用意に曝露するリスク、それによるクラウド環境の侵害を軽減することができます。 

**期待される成果: **ルートユーザーをセキュリティ保護することにより、ルートユーザー認証情報を不正使用した場合の偶発的または意図的な損害が生じる可能性が低減されます。検出コントロールを確立することによっても、ルートユーザーを使ったアクションが取られると適切な担当者にアラートを送信できます。

**一般的なアンチパターン:**
+  ルートユーザー認証情報を必要とする少数以外のタスクに対してもルートユーザーを使用する。  
+  緊急時に重要なインフラストラクチャ、プロセス、担当者が正常に機能するかどうかを検証するために、定期的な緊急時対応計画のテストを怠っている。
+  典型的なアカウントログインフローのみを考慮し、代替アカウント回復方法を考慮することも、テストすることもしていない。
+  DNS、E メールサーバー、および携帯電話会社がアカウント復旧フローで使用されるにもかからず、重要なセキュリティ境界の一部として対処していない。

 **このベストプラクティスを活用するメリット:** ルートユーザーへのアクセスを確保することにより、アカウントでアクションをコントロールおよび監査できるという安心感が向上する。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>

 AWS は、アカウントを保護するのに役立つ多くのツールを提供しています。ただし、これらの対策の一部は既定では有効になっていないため、実装するには直接的な措置を講じる必要があります。これらの推奨事項を、AWS アカウント をセキュリティ保護するための基本的なステップと考えてください。これらのステップを実装する際、セキュリティ管理を継続的に評価およびモニタリングすることが重要となります。 

 AWS アカウント を初めて作成する際は、アカウント内のすべての AWS のサービスとリソースに完全なアクセス許可を持つ 1 つの ID から始めます。この ID は、AWS アカウント のルートユーザーと呼ばれます。アカウント作成に使用した E メールアドレスとパスワードを使用すれば、ルートユーザーとしてログインできます。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 つのアカウントを管理アカウントに指定し、その管理アカウントの下に何層ものメンバーアカウントを追加することができます。管理アカウントのルートユーザーのセキュリティ保護を優先してから、メンバーアカウントのルートユーザーに対処してください。管理アカウントのルートユーザーをセキュリティ保護する戦略は、メンバーアカウントのルートユーザーとは異なり、メンバーアカウントのルートユーザーに対しては予防的なセキュリティコントロールを講じることができます。 

### 実装手順
<a name="implementation-steps"></a>

 ルートユーザーのコントロールを確立するには、次の実装ステップが推奨されます。該当する場合、推奨事項は [CIS AWS Foundations ベンチマークバージョン 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 を使用して新しいアカウントを作成している場合、新規メンバーアカウントのルートユーザーの初期パスワードはランダムな値に設定され、決して公開されることはありません。必要に応じ、AWS Organization 管理アカウントからのパスワードリセットフローを使って、[メンバーアカウントへのアクセス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root)を獲得することを検討してください。

   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//latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) または [ハードウェア MFA デバイス](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root)のいずれかを有効化する手順に従ってください。

   1.  バックアップ用に複数の MFA デバイスを登録することを検討してください。 [アカウントごとに最大 8 台の MFA デバイスを登録できます](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//latest/UserGuide/id_credentials_passwords_change-root.html)することにより、誤って露出したパスワードが不正使用されるリスクを低減します。

### 検出コントロール
<a name="detective-controls"></a>
+  ルート認証情報の使用を検出するアラームを作成します (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)を評価および実装します。

### 運用ガイダンス
<a name="operational-guidance"></a>
+  組織で、ルートユーザー認証情報へのアクセスが必要な担当者を決定します。
  +  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)に記載されたベストプラクティスを参照してください。

## リソース
<a name="resources"></a>

**関連するベストプラクティス:** 
+ [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//latest/UserGuide/best-practices.html) 
+  [Amazon GuardDuty – ルート認証情報使用アラート](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/securityhub-cis-controls-1.4.0.html#securityhub-cis1.4-controls-1.7) 
+  [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/) 

**関連動画:** 
+  [自動化とガバナンスにより AWS の大規模な採用を可能にする](https://youtu.be/GUMSgdB-l6s) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) (Well-Architected の手法によるセキュリティのベストプラクティス) 
+  [AWS re:inforce 2022 – Security best practices with AWS IAM からの「Limiting use of AWS root credentials (AWS ルート認証情報の使用を制限する)](https://youtu.be/SMjvtxXOXdU?t=979)」

**関連する例とラボ:** 
+  [ラボ: AWS アカウント and root user](https://www.wellarchitectedlabs.com/security/100_labs/100_aws_account_and_root_user/) (AWS アカウントのセットアップとルートユーザー) 

# SEC01-BP03 管理目標を特定および検証する:
<a name="sec_securely_operate_control_objectives"></a>

 脅威モデルから特定されたコンプライアンス要件とリスクに基づいて、ワークロードに適用する必要がある管理目標および管理を導き出し、検証します。管理目標と制御を継続的に検証することは、リスク軽減の効果測定に役立ちます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  コンプライアンス要件を特定する: ワークロードが準拠する必要のある組織要件、法的要件、規制要件を確認します。 
+  AWS コンプライアンスリソースを特定する: コンプライアンスを支援するために使用できる AWS のリソースを特定します。 
  +  [https://aws.amazon.com/compliance/ ](https://aws.amazon.com/compliance/)
  + [ https://aws.amazon.com/artifact/](https://aws.amazon.com/artifact/) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+ [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 セキュリティ脅威に関する最新情報を入手する:
<a name="sec_securely_operate_updated_threats"></a>

 適切な制御を定義して実装するために、最新のセキュリティ脅威を常に把握して攻撃ベクトルを認識します。AWS Managed Services を利用することで、AWS アカウントにおける予期しない動作や異常な動作の通知を簡単に受けることができます。セキュリティ情報フローの一環として、AWS Partner ツールまたはサードパーティーの脅威情報フィードの利用を検討します。それらの [共通脆弱性識別子 (CVE) リスト ](https://cve.mitre.org/) には、一般に公開されているサイバーセキュリティの脆弱性が含まれており、最新の情報を入手するために利用することができます。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  脅威インテリジェンスソースを購読する: ワークロードで使用しているテクノロジーに関連する、複数のソースからの脅威インテリジェンス情報を定期的に確認します。 
  +  [共通脆弱性識別子リスト ](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) サービスを検討する: ワークロードがインターネットに接続できる環境であれば、インテリジェンスソースをほぼリアルタイムで可視化することができます。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+ [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 セキュリティに関する推奨事項を常に把握する
<a name="sec_securely_operate_updated_recommendations"></a>

 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) は、セキュリティおよびプライバシー通知に関する重要な情報を含みます。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) 

 **関連動画:** 
+  [Well-Architected の手法によるセキュリティのベストプラクティス](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP06 パイプラインのセキュリティコントロールのテストと検証を自動化する
<a name="sec_securely_operate_test_validate_pipeline"></a>

 ビルド、パイプライン、プロセスの一環としてテストおよび検証されるセキュリティメカニズムの安全なベースラインとテンプレートを確立します。ツールとオートメーションを使用して、すべてのセキュリティコントロールの継続的なテストと検証を実施します。たとえば、マシンイメージやインフラストラクチャなどの項目をコードテンプレートとしてスキャンして、セキュリティの脆弱性、不規則性、ドリフトを各ステージで確立されたベースラインから確認します。AWS CloudFormation Guard を使用すると、CloudFormation が安全なことを検証し、時間を節約し、設定エラーのリスクを低減するのに役立ちます。 

本番環境に取り込まれるセキュリティの誤設定の数を減らすことが非常に重要です。ビルドプロセスでより適切な品質管理をより多く実行し、欠陥の数を減らすことができれば、より優れたものになります。継続的インテグレーションおよび継続的デプロイ (CI/CD) のパイプラインは、可能な限りセキュリティの問題をテストできるように設計する必要があります。CI/CD パイプラインは、ビルドと配信の各段階でセキュリティを強化する機会を提供します。CI/CD セキュリティツールも更新して、進化する脅威を軽減する必要があります。

ワークロード設定への変更をトラッキングして、監査、変更管理、および該当する可能性がある調査へのコンプライアンスに役立てます。AWS Config を使用して、AWS およびサードパーティーリソースを記録および評価できます。これにより、ルールやコンフォーマンスパックへの全体的なコンプライアンスを継続的に監査および評価できます。コンフォーマンスパックとは、是正措置に関する一連のルールのことです。

変更トラッキングには、組織の変更管理プロセス (MACD-Move/Add/Change/Delete とも呼ばれる) の一部である計画されていた変更、予定外の変更、インシデントなどの予期しない変更を含める必要があります。変更はインフラストラクチャで発生する場合もあれば、コードリポジトリの変更、マシンイメージおよびアプリケーションインベントリの変更、プロセスとポリシーの変更、ドキュメントの変更などの他のカテゴリに関連するものである場合もあります。

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  設定管理を自動化する: 設定管理サービスまたはツールを使用して、リモートでアクションを実行し、安全な設定を自動的に適用および検証します。 
  +  [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/)

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける
<a name="sec_securely_operate_threat_model"></a>

 脅威のモデル化を実行し、ワークロードの潜在的脅威と関連付けられた緩和策を特定し、最新の状態を維持します。脅威に優先順位を付け、セキュリティコントロール緩和策を調整して防止、検出、対応を行います。ワークロードの内容、および進化するセキュリティ環境の状況に応じてセキュリティコントロールを保持および維持します。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>

 **脅威のモデル化とは何ですか?** 

 「脅威のモデル化は、価値のある対象を保護する文脈で、脅威と緩和策を特定、伝達、理解するためのもの」 – [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)の業界原則と一致しています。最終的に脅威のモデル化は組織のリスク管理プロセスと統合し、脅威駆動型アプローチを使用して、実装するコントロールの決定を促します。 

 **脅威のモデル化は、いつ実行すべきですか?** 

 ワークロードのライフサイクルにおけるできるだけ早い段階で脅威のモデル化を開始することにより、より柔軟に特定した脅威への対策を実施できるようになります。ソフトウェアのバグと同様、脅威を特定するのが早いほど、その対策のコスト効率が向上します。脅威モデルはライブドキュメントであり、ワークロードの変化に応じて進化し続ける必要があります。大きな変化、脅威の状況における変化が生じた場合や、新たな機能またはサービスを採用した場合などを含む、経時的な脅威モデルを保持します。 

### 実装手順
<a name="implementation-steps"></a>

 **脅威のモデル化の実行方法を教えてください** 

 脅威のモデル化にはさまざまな実行方法があります。プログラミング言語と同様、それぞれに長所と短所があり、自分に最も適した方法を選択する必要があります。1 つのアプローチは、[Shostack’s 4 Question Frame for Threat Modeling (脅威のモデル化のための Shostack の 4 つの質問フレーム)](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)) などの脅威を特定するモデルを使用すると実施しやすくなります。これは、評価するためのさまざまなカテゴリ (スプーフィング、改ざん、否認、情報漏洩、サービス拒否、権限昇格) を提案するものです。さらに、既存のリストを見直し、[OWASP トップ 10](https://owasp.org/www-project-top-ten/)、[HiTrust 脅威カタログ](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 サービス自体のセキュリティコントロール緩和のためには、たとえば、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 セキュリティブログの「[How to approach threat modeling (脅威のモデル化にアプローチする方法)](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)」を参照してください。 

 **Threat Composer** 

 脅威のモデル化の実行に役立てるため、[Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) ツールの使用を検討してください。脅威のモデル化における価値実現までの時間の短縮を目的としたツールです。このツールは、以下の用途で役立ちます。 
+  [脅威の文法](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar)に沿って、自然な非線形のワークフローに当てはまる有益な脅威の文章を記述する 
+  人間が読める脅威モデルを生成する 
+  機械可読な脅威モデルを生成して、脅威モデルをコードとして扱えるようにする 
+  Insights Dashboard を使用して、品質や対象範囲を改善できる分野をすばやく特定する 

 詳細については、Threat Composer にアクセスして、システム定義の **Example Workspace** に切り替えてください。 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [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-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 modelling](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 ワークショップ ](https://catalog.workshops.aws/threatmodel)

 **関連ツール:** 
+  [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 

# SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する
<a name="sec_securely_operate_implement_services_features"></a>

 ワークロードのセキュリティ体制を進化させることができる、AWS および AWS パートナーのセキュリティサービスと機能を評価および実装します。AWS セキュリティブログは、新しい AWS サービスおよび機能、実装ガイド、および一般的なセキュリティガイダンスを取り上げます。[「AWS の最新情報」](https://aws.amazon.com/new) は、すべての AWS 機能、サービス、および発表に関する最新情報を確認する優れた方法です。

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  定期的なレビューを計画する: コンプライアンス要件、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)

## リソース
<a name="resources"></a>

 **関連動画:** 
+  [Well-Architected の手法によるセキュリティのベストプラクティス ](https://youtu.be/u6BCVkXkPnM)