『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』から学んだ覚えておきたいこと

こんにちは。
AWSの技術本として佐々木拓郎さん(@dkfj)が
AWSにおけるアカウントセキュリティに関する本を出版されていたので
拝読させて頂きました

感想

AWSにおいてセキュリティにまつわるサービスは非常に多岐に渡ってリリースされており
重複と思われるような機能も存在する中で各サービスの特徴だけでなく使い分けに関する考え方などもまとめられており非常に勉強になりました。

また、マルチアカウントの運用という観点で本の大部分が記載されているAWS本は珍しく
現場でマルチアカウントを運用している私としてはその点でもとてもありがたかったです。
実際に手を動かしてみるというチャプターもあり、AWSの基本知識は必要ですが
前提知識を抑えた初学者にも優しい構成になっているように感じました。

備忘用

以下は完全に個人的に覚えておきたい本の内容を記載していきます
読みながらまとめたものを貼っただけなので、可読性完全無視です。 興味がある方は、複数のAWSアカウントの運用者は後悔しないと思います。
ぜひBOOTHで購入して読んでみてください。

booth.pm

Macie

概要さえよく知らなかったAWSサービス
S3バケットに保存されたデータを検出、分類、保護する機械学習サービス
CloudTrailと連携してどのユーザーからどんなAPIアクセスがあったかを分析することもできる
アクセスパターンの分析によって、「普段そのバケットを利用しないユーザーが大量のソースコードをダウンロードしている」ことを検知して
CloudWatchでアラートに連携するということも可能

Organizationsが作るロール

Organizaitonsから作成したメンバーアカウントのIAMロールに「OrganizaitonAccountAccessRole」が作成される
→Organizaitonのマスターアカウントから各メンバーアカウントを管理するためのロール
【運用上の注意点】
マスターアカウントのユーザーからスイッチしてログインすることができる
※信頼関係の設定で「マスターアカウントのユーザーすべてからスイッチできる」ようになっている
【対応策】

• マスターアカウントには必要最小限のIAMユーザーのみしか作らないようにする
  
• OrganizaitonAccountAccessRoleの信頼関係を絞る（筆者はこちらを推奨）
  

SecurityHub

複数のアカウントの状況を一括してモニタリングするサービス
様々なAWSサービスからのセキュリティリスク情報を収集

• Inspector
• FirewallManager:複数のAWSアカウントのWAF/Shield/SGを一元管理できる
• IAMAccessAnalyzer:外部公開が可能なAWSサービスが不要に公開されていないかを確認することに重点を置いたサービス ※IAMロール/KMS/SQSを対象にすることが可能（ConfigRulesとの比較として知らなかった点）

統合サービスSecurityHubの位置づけ

GuardDutyで検知した脅威のCloudWatahEventsへの連携方法

• AmazonGuardDuty→SecurityHub経由でCloudWatchEventsへの連携

  • SecurityHubFindings
    • Imported
    • CustomAction（人間が一度検知内容を確認して後続の処理を呼び出すことを選択できる）
    • Results
  • AWSAPICallviaCloudTrail

• AmazonGuardDuty→CloudWatchEventsへ連携
  
  【使い分けの考え方】←超勉強になった

• GuardDutyから直接対処する→リアルタイムで自動的に防御すべきもの

• SercurityHub経由で対処する→リアルタイム性が低く内容を人間が判断すべきもの
  
  SecurityHubにはコンプライアンスへの準拠状況をチェックする機能もある
  現状は以下を基準にチェックする
  

• CIS AWS FoundationsBenchmarkv1.2.0

• PCI DSS v3.2.1
  【準拠状況へのマインドセット】
  必ず100%にしなければいけない×
  基準を満たしていない部分を把握して、どういった対策が必要かどうか調べた上で対策するかどうかを判断する○
  

※SecurityHubは今後セキュリティ管理の中核として重要になっていくのでとりあえず設定して稼働しておく方がベター

通知

【通知設定の考え方】
重要なものや単なるお知らせ程度のものまで、同じように受信して対応していると運用はすぐに破綻する

対処の重要度ごとに通知方法を変える

• 重要度が高いものほど、同期性が高いものにする
  
• 重要度が低いものについては、メール等の同期性が低いものにする
  

• とりあえず通知ではなく、送らずに済ませられないかをまず考える
  
  通知は人間の判断・対処が必要なものを送る
  

• 人間の判断が不要なものは通知しない

• 自動で対処可能なものは、通知なしで自動対処
• 自動処理したものは、結果をわかるようにだけする

対応と復旧

AWSではAPIを通じて自動で元の状態に戻すことは簡単なので、復旧を自動化することを目指す
ただし、最初から復旧を作りこむのではなく、実装コストとメリットを見極めて自動化をおこなう
* 有効なサービス * Lambda * CloudFormation * SSM Automation EC2 →　ConfigRules(ルールから外れた設定の検知) →修復アクションの呼び出し→AWS SystemsManager(Automation)で自動修復

参考URL

【新サービス】機械学習を使って不正なアクセスパターンを検出、対応するAmazon MacieがLaunch。 | Developers.IO

IAM Access Analyzerと既存の機能を比較してどう使っていくか考察してみた #reinvent | Developers.IO