

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

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

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

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

セキュリティとインフラストラクチャを念頭に置いて、ワークロードが増大するにつれて組織が共通のガードレールを設定できるようにします。このアプローチによって、ワークロード間の境界と制御が確立します。開発環境およびテスト環境から本番環境を分離する場合、または外部コンプライアンス要件 (PCI-DSS や HIPAA など) で定義されている機密レベルの異なるデータを処理するワークロードとそうでないワークロードとの間に強力な論理的境界を設ける場合は、アカウントレベルの分離を強くお勧めします。

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

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

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

 **関連するドキュメント:** 
+ [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 アカウント をセキュリティ保護する
<a name="sec_securely_operate_aws_account"></a>

AWS アカウント のセキュリティ保護には、 [ルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)の保護および使用の回避、連絡先情報を最新の状態に保つなど、さまざまな側面があります。専用のインフラストラクチャで [AWS Organizations](https://aws.amazon.com/organizations/) AWS を使用すれば、ワークロードの拡大やスケーリングに合わせて、アカウントを一元管理できます。AWS Organizations は、アカウント全体の管理、制御の設定、サービスの構築に役立ちます。

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

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

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

 **関連するドキュメント:** 
+ [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 管理目標を特定および検証する:
<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>

 脅威モデルを使用して潜在的な脅威を特定し、その登録を最新の状態に維持します。脅威に優先順位を付け、セキュリティコントロールを調整して防止、検出、対応を行います。進化するセキュリティ環境の状況に応じてセキュリティコントロールを再確認および維持します。 

脅威のモデル化は、設計プロセスの早い段階でセキュリティ上の問題を発見して対処するのを支援する体系的なアプローチを提供します。ライフサイクルの後半に緩和策を講じるよりも、早い段階で緩和策を講じた方がコストがかからないからです。

脅威のモデル化の典型的なコアステップは次のとおりです。

1. アセット、アクター、エントリポイント、コンポーネント、ユースケース、信頼レベルを特定し、これらを設計図に記載する。

1. 脅威のリストを特定する。

1. 各脅威について、セキュリティコントロールの実装を含む緩和策を特定する。

1. リスクマトリックスを作成し、脅威が適切に緩和されているかどうかを確認する。

脅威のモデル化は、ワークロード (またはワークロードの機能) レベルで行うのが最も効果的であり、すべてのコンテキストが評価に利用できることを保証します。セキュリティ状況の変化に応じて、このマトリックスを見直し、維持してください。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  脅威モデルを作成する: 脅威モデルは、潜在的なセキュリティ脅威を特定して対処するのに役立ちます。 
  +  [NIST: Guide to Data-Centric System Threat Modeling (データ中心システム脅威のモデル化へのガイド) ](https://csrc.nist.gov/publications/detail/sp/800-154/draft)

## リソース
<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/)

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

# 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)