# アーキテクチャ図の文書化と一元化
<a name="document-and-centralize-architecture-diagrams"></a>

 セキュリティイベントに迅速かつ正確に対応するには、システムとネットワークがどのように設計されているかを理解する必要があります。これらの内部パターンを理解することは、インシデント対応だけでなく、そのパターンがベストプラクティスに従って設計されているというアプリケーション間の一貫性を検証する上でも重要です。また、この文書が最新であり、新しいアーキテクチャパターンに従って定期的に更新されていることを確認する必要があります。次のような項目を詳述する文書と内部リポジトリを作成する必要があります。
+ **AWS アカウント構造** - 以下を把握しておく必要があります。
  +  AWS アカウントはいくつ存在するか?
  +  それらの AWS アカウントはどのように整理されているか?
  +  AWS アカウントのビジネスオーナーは誰か?
  +  サービスコントロールポリシー (SCP) を使用しているか？ 使用している場合、SCP を使用してどのような組織的なガードレールが実装されているか?
  +  使用できるリージョンとサービスを制限しているか?
  +  ビジネスユニットと環境 (dev/test/prod) にどのような違いがあるか?
+ **AWS サービスパターン** 
  +  どの AWS サービスを使用しているか?
  +  最も広く使用されている AWS サービスは何か?
+ **アーキテクチャパターン** 
  +  どのクラウドアーキテクチャを使用しているか?
+ **AWS 認証パターン** 
  +  デベロッパーは通常、AWS をどのように認証しているか?
  +  IAM ロールまたはユーザー (またはその両方) を使用しているか? AWS の認証は ID プロバイダー (IdP) に接続されているか?
  +  IAM ロールまたはユーザーを従業員またはシステムにどのように対応付けているか?
  +  権限がなくなった人のアクセス権をどのように取り消しているか?
+ **AWS 認可パターン** 
  +  開発者はどのような IAM ポリシーを使用しているか?
  +  リソースベースのポリシーを使用しているか?
+ **ログ記録とモニタリング** 
  +  使用しているログ記録のソースと保存場所は?
  +  AWS CloudTrail ログを集計しているか? 集計している場合、どこに保存しているか?
  +  CloudTrail ログをどのようにクエリしているか?
  +  Amazon GuardDuty が有効になっているか?
  +  GuardDuty の検出結果 (コンソール、チケットシステム、SIEM など) にどのようにアクセスしているか?
  +  検出結果またはイベントは SIEM に集約されているか?
  +  チケットは自動的に作成されるか?
  +  調査用にログを分析するためにどのようなツールが用意されているか?
+ **ネットワークトポロジ** 
  +  ネットワーク上のデバイス、エンドポイント、および接続は、物理的または論理的にどのように配置されているか?
  +  ネットワークは AWS とどのように接続されているか?
  +  ネットワークトラフィックは環境間でどのようにフィルタリングされているか?
+ **外部インフラストラクチャ** 
  +  外部向けアプリケーションはどのようにデプロイされているか?
  +  パブリックアクセス可能な AWS リソースは何か?
  +  外部向けインフラストラクチャが含まれている AWS アカウントは?
  +  どのような DDoS または外部フィルタリングが使用されているか?

 内部のテクニカルな図およびプロセスを文書化すると、インシデント対応アナリストが業務を容易に行えるようになり、セキュリティイベントに対応するための制度上の知識を迅速に取得できます。内部のテクニカルプロセスの詳細な文書化は、セキュリティ調査を簡素化するだけでなく、プロセスの合理化と評価も調整します。