

# ベストプラクティス
<a name="sec-bp"></a>

**Topics**
+ [セキュリティ](sec-security.md)
+ [ID とアクセス管理](sec-iam.md)
+ [検知](sec-detection.md)
+ [インフラストラクチャ保護](sec-infrastructure.md)
+ [データ保護](sec-dataprot.md)
+ [インシデント対応](sec-incresp.md)

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

 ワークロードを安全に運用するには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。組織レベルおよびワークロードレベルにおいて、「運用上の優秀性」で定義した要件とプロセスを抽出し、それらをすべての領域に適用します。 

 AWS や業界のレコメンデーションおよび脅威インテリジェンスを最新に保つことで、脅威モデルと管理目標を進化させることができます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティオペレーションを拡張できます。 

 以下の質問は、セキュリティに関する考慮事項に焦点を当てています。(セキュリティに関する質問、回答、およびベストプラクティスの一覧については、 [付録](a-security.md)を参照してください)。


| SEC 1: ワークロードを安全に運用するには、どうすればよいですか? | 
| --- | 
| ワークロードを安全に運用するには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。組織レベルおよびワークロードレベルにおいて、「運用上の優秀性」で定義した要件とプロセスを抽出し、それらをすべての領域に適用します。AWS や業界筋、脅威インテリジェンスからの推奨事項を常に把握することで、脅威モデルや管理目標を向上させることができます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティオペレーションを拡張できます。 | 

 AWS における推奨アプローチは、機能およびコンプライアンスまたはデータの機密性要件に基づいて、アカウントごとに異なるワークロードを分離することです。 

# ID とアクセス管理
<a name="sec-iam"></a>

 アイデンティティとアクセスの管理は情報セキュリティプログラムの主要パートです。これにより、お客様が意図した方法で認可、認証されたユーザーおよびコンポーネントのみがリソースにアクセスできるようになります。たとえば、プリンシパル (つまり、お客様のアカウントに対してアクションをとるアカウント、ユーザー、ロール、サービス) を定義し、これらのプリンシパルに合わせたポリシーを構築し、強力な認証情報管理を実装できます。これらの権限管理機能は認証と承認の中枢となっています。 

 AWS では、権限管理は主に AWS Identity and Access Management (IAM) サービスによってサポートされており、AWS のサービスとリソースへのユーザーやプログラムによるアクセスの制御を可能にしています。詳細なポリシーを適用し、ユーザー、グループ、ロール、またはリソースに権限を割り当てることができます。また、複雑性レベル、再利用禁止、多要素認証 (MFA) の強制など、強力なパスワード設定をする機能があります。また既存のディレクトリサービスでフェデレーションを使用することもできます。AWS へのアクセス権を持つシステムを必要とするワークロードでは、IAM は、ロール、インスタンスプロファイル、ID フェデレーション、一時的認証情報によって安全なアクセスを実現します。 

 以下の質問は、セキュリティに関する考慮事項に焦点を当てています。 


| SEC 2: ユーザー ID とマシン ID はどのように管理するのですか? | 
| --- | 
|  AWS ワークロードを安全に運用するには、2 種類の ID を管理する必要があります。管理およびアクセス権を付与する必要があるアイデンティティのタイプを理解することで、適切な ID が適切な条件下で適切なリソースにアクセスできるようになります。 ユーザー ID: 管理者、開発者、オペレーター、エンドユーザーは、AWS 環境とアプリケーションにアクセスするために ID を必要とします。これらは、組織のメンバー、または共同作業を行う外部ユーザーであり、ウェブブラウザ、クライアントアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースを操作する人たちです。 マシン ID: サービスアプリケーション、運用ツール、ワークロードには、データの読み取りなどのために、AWS のサービスにリクエストを送信するための ID が必要です。このような ID には、Amazon EC2 インスタンスや AWS Lambda 関数など、AWS 環境で実行されているマシンが含まれます。また、アクセスを必要とする外部関係者のマシン ID を管理することもできます。さらに、AWS 環境にアクセスする必要があるマシンが AWS 外にある場合もあります。   | 


| SEC 3: ユーザーとマシンのアクセス許可はどのように管理するのですか? | 
| --- | 
| アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。権限を分けることで、どのような条件で誰が何にアクセスできるかを制御します。 | 

 すべてのユーザーやシステムが認証情報を共有してはいけません。ユーザーアクセス権は、パスワード要件や MFA の強制などのベストプラクティスを実践した上で、最小権限で与えられるべきです。AWS サービスへのAPIコールを含むプログラムによるアクセスは、AWS Security Token Service が発行するような一時的かつ限定的な認証情報を使用して実行する必要があります。 

 AWS では、Identity and Access Management に役立つリソースを提供しています。ベストプラクティスを学ぶには、 [認証情報と認証の管理](https://wellarchitectedlabs.com/Security/Quest_Managing_Credentials_and_Authentication/README.html?ref=wellarchitected-wp)io1 [人為的なアクセスの制御](https://wellarchitectedlabs.com/Security/Quest_Control_Human_Access/README.html?ref=wellarchitected-wp)、および [プログラムによるアクセスの制御のハンズオンラボを参照してください](https://wellarchitectedlabs.com/Security/Quest_Control_Programmatic_Access/README.html?ref=wellarchitected-wp)。 

# 検知
<a name="sec-detection"></a>

 発見的統制により、セキュリティの潜在的な脅威やインシデントを特定できます。これはガバナンスフレームワークの最重要機能であり、品質管理プロセス、法的義務またはコンプライアンス義務、脅威の特定とその対応のサポートのために、この機能を使用できます。さまざまな種類の発見的統制があります。例えば、アセットとそれらの詳細な属性のインベントリを実行することで、より効果的に意思決定やライフサイクル管理を行い、運用の基準を確立できます。また、内部監査という、情報システムに関連するコントロールの検査を行って、ポリシーと要件に準拠し、定義した条件に基づいて正確に自動化されたアラート通知を設定できます。これらのコントロールは、組織が異常なアクティビティの範囲を特定し把握するのに役立つ重要な対応機能です。 

 AWS では、監査、自動分析、アラームを可能にするログ、イベント、監視を処理することで、検出制御を実装することができます。CloudTrail ログ、AWS API コール、CloudWatch はアラームによるメトリクスのモニタリングを、AWS Config は設定履歴を提供します。Amazon GuardDutyは、悪意ある動作や不正な挙動を継続的に監視し、AWS アカウントとワークロードの保護を支援するマネージド脅威検知サービスです。サービスレベルのログも利用できます。たとえば、Amazon Simple Storage Service (Amazon S3) を使用してアクセスリクエストをログに記録することができます。 

 以下の質問は、セキュリティに関する考慮事項に焦点を当てています。 


| SEC 4: セキュリティイベントは、どのように検出して調査するのですか? | 
| --- | 
| ログやメトリクスからイベントを可視化して把握し、分析します。セキュリティイベント、および潜在的な脅威に対する措置を講じて、ワークロードの保護に役立てます。 | 

 ログ管理は、セキュリティやフォレンジックから、規制や法的要件に至るまで、Well-Architected ワークロードにとって重要です。潜在的セキュリティインシデントを特定するためには、ログを分析して対応することが不可欠です。AWS では、データ保持のライフサイクルを定義したり、データの保存先、アーカイブ先、最終的な削除先を定義することで、ログ管理を容易にする機能を提供しています。予測可能で信頼性の高いデータ処理が、さらに簡単かつ費用対効果の高いものになります。 

# インフラストラクチャ保護
<a name="sec-infrastructure"></a>

 インフラストラクチャの保護には、ベストプラクティスと組織の義務または規制上の義務に準拠するために必要な、多層防御などの制御手段が含まれます。これらの手段を用いることは、クラウドやオンプレミスの環境で滞りなく運用していくために特に重要です。 

 AWS では、AWS ネイティブのテクノロジーを使用して、または AWS Marketplace から利用できるパートナー製品およびサービスを使用して、ステートフルおよびステートレスのパケットインスペクションを実装できます。Amazon Virtual Private Cloud (Amazon VPC) を使用して、プライベートでセキュアかつスケーラブルな環境を構築でき、この環境内でゲートウェイ、ルーティングテーブル、パブリックおよびプライベートのサブネットなどのトポロジーを定義できます。 

 以下の質問は、セキュリティに関する考慮事項に焦点を当てています。 


| SEC 5: ネットワークリソースはどのように保護するのですか? | 
| --- | 
| 何らかの形式のネットワーク接続があるワークロードは、インターネットでもプライベートネットワークでも、外部および内部ネットワークベースの脅威から保護するために、複数の防御レイヤーが必要です。 | 


| SEC 6: コンピューティングリソースはどのように保護するのですか? | 
| --- | 
| ワークロード内のコンピューティングリソースを内外の脅威から守るには、複数の防御レイヤーを設ける必要があります。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。 | 

 すべての環境で複数レイヤーを防御するのが賢明です。インフラストラクチャ保護では、そのコンセプトとメソッドの多くがクラウドとオンプレミスの両方に対して有効です。境界保護の強制、イングレスおよびエグレスのモニタリングポイント、包括的なログ記録、モニタリング、アラートはすべて、効果的な情報セキュリティ計画には必須です。 

 AWS のお客様は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS) コンテナ、または AWS Elastic Beanstalk インスタンスの設定をカスタマイズまたは強化し、その設定を変更不能な Amazon マシンイメージ (AMI) に永続化することができます。そして、この AMI を使用して起動するすべての新しい仮想サーバー (インスタンス) は、Auto Scaling でトリガーするか手動で起動して、その強化した設定を引き継ぐことができます。 

# データ保護
<a name="sec-dataprot"></a>

 システムを設計する前に、セキュリティに影響を与える基本的なプラクティスを実施する必要があります。例えば、データ分類は組織のデータを機密性レベルに基づいてカテゴリーに分類し、暗号化は認証されていないアクセスに対してデータが開示されてしまうことを防ぎます。これらのツールやテクニックは、金銭的な損失の予防や規制遵守という目的を達成するためにも重要です。 

 AWS では、以下の取り組みによりデータの保護に努めています。 
+  AWS ユーザーとして、お客様はご自身のデータを完全に管理することができます。 
+  AWS では、データの暗号化や定期的な鍵のローテーションなど、鍵の管理を AWS で簡単に自動化したり、お客様自身でメンテナンスすることができます。 
+  ファイルのアクセスや変更など、重要なコンテンツを含む詳細なログを記録できます。 
+  AWS には優れた回復力を持つストレージシステムを設計しています。たとえば、Amazon S3 S3 Standard、S3 Standard–IA、S3 One Zone-IA、Amazon Glacier はすべて、1 年間にオブジェクトの 99.999999999% の堅牢性を実現するよう設計されています。この堅牢性レベルは、オブジェクトの予想される年平均損失の 0.000000001% に相当します。 
+  大規模データライフサイクル管理プロセスの一部であるバージョニングにより、間違って上書きしたり削除したりしてデータが損なわれることを防ぎます。 
+  AWS ではリージョン間のデータの移動は発生しません。1 つのリージョンにあるコンテンツは、リージョン間の移動を可能にする機能を明示的に有効にしたり、その機能を提供するサービスを使用したりしない限りは、そのリージョンにとどまります。 

 以下の質問は、セキュリティに関する考慮事項に焦点を当てています。 


| SEC 7: データをどのように分類すればよいですか? | 
| --- | 
| 分類方法を確立すると、重要度と機密性に基づいてデータをカテゴリ別に分類して、各カテゴリに適した保護と保持方法でデータを管理できるようになります。 | 


| SEC 8: 保管中のデータはどのように保護するのですか? | 
| --- | 
| 複数のコントロールを実装して保管中のデータを保護し、不正アクセスや不正処理のリスクを低減します。 | 


| SEC 9: 転送中のデータはどのように保護するのですか? | 
| --- | 
| 複数のコントロールを実装して、転送中のデータを保護し、不正アクセスや損失のリスクを軽減します。 | 

 AWS には、保存中および伝送中のデータを暗号化する手段が複数あります。データの暗号化を容易にする機能を各サービスに搭載しています。たとえば、Amazon S3 にはサーバー側の暗号化 (SSE) を実装しているため、簡単にデータを暗号化して保存することができます。HTTPS の暗号化と復号化のプロセス全体 (一般に SSL termination として知られているプロセス) を、Elastic Load Balancing (ELB) によって処理されるように調整することもできます。 

# インシデント対応
<a name="sec-incresp"></a>

 非常に優れた予防的、発見的統制が実装されていてもなお、組織はセキュリティインシデントの潜在的な影響に対応し、影響を緩和する手段を講じる必要があります。ワークロードのアーキテクチャは、インシデントの際にチームが効果的に対応できるかどうか、システムを隔離するかどうか、運用を既知の正常な状態に復元できるかどうかに大きく影響します。セキュリティインシデントが起きる前にツールとアクセスを実践し、本番を想定したインシデント対応を定期的に実施することで、タイムリーな調査と復旧を可能にするアーキテクチャを構築できます。 

 AWS では、以下の取り組みにより効果的なインシデント対応を実現しています。 
+  ファイルのアクセスや変更など、重要なコンテンツを含む詳細なログを記録できます。 
+  イベントを自動的に処理でき、AWS API の使用によって、対応を自動化するツールを起動することができます。 
+  AWS CloudFormation を使用して、ツールと「クリーンルーム」を事前にプロビジョニングできます。これにより、安全で隔離された環境でフォレンジックを実行できます。 

 以下の質問は、セキュリティに関する考慮事項に焦点を当てています。 


| SEC 10: インシデントの予測、対応、復旧はどのように行うのですか? | 
| --- | 
| 組織に支障をきたすことを最小限に抑えるために、セキュリティインシデントのタイムリーで効果的な調査、対応、復旧に備えることが重要です。 | 

 お客様のセキュリティチームにすばやくアクセス権を付与し、インスタンスの隔離を自動化するとともに、フォレンジックのデータと状態のキャプチャを自動化します。 