「[目指せ上級者] 最強にセキュアなAWSアカウントの作り方」というタイトルでDevelopersIO 2022に登壇しました #devio2022

クラスメソッドの年1回の大型イベント、DevelopersIO 2022で登壇した「[目指せ上級者] 最強にセキュアなAWSアカウントの作り方」の解説です。

DevelopersIO 2022

#AWS Security Hub

#AWS

#セキュリティ

臼田佳祐

2022.07.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、AWSのセキュリティ確保してますか？(挨拶

今回は年1回の弊社大型イベントDevelopersIO 2022で登壇した「[目指せ上級者] 最強にセキュアなAWSアカウントの作り方」というセッションの登壇ブログです。ぜひ登録して他のライブセッションやオンデマンドセッションもお楽しみください。アーカイブもあがります。

動画

資料

解説

今回のタイトルは「[目指せ上級者] 最強にセキュアなAWSアカウントの作り方」という形で、セッションのレベルは400、上級者向けのものです。

またいつもどおりパッション強めの内容でした。

セッションのテーマは「自分たちの最強のAWS環境を作ろう」です。これは後から何回か出てきますので覚えておいてください。

セッション対象者

プロジェクトのAWSアカウント管理者
組織のAWSアカウント管理者
セキュリティ担当者
セキュリティ責任者
AWS利用者

と書いていますが、まあいつもどおり幅広い方が巻き込まれてほしいなーという気持ちです。ただ初心者向けではありません。上級者と上級者を目指す方に届け！

長い前置き

最強のAWSアカウントを作っていく

とはどうやってやっていくのか？

上級者を目指している皆様であればよくご存知だと思いますが、AWSのアカウントを作ったらだいたい下記の設定を入れていきます。

CloudTrail
Config
GuardDuty
Security Hub
IAM Access Analyzer
Detective
などなど

これらが入っていれば最強にセキュアなAWSアカウント何でしょうか…？こんな感じの構成ですね。

…

……

………

こんな前フリをするということは、答えはもちろんNoです。

いくらAWSアカウント作成時にガッチリセキュアに作っていっても、その上に実際に利用するリソースを作っていくわけですから、そちらもカバーしなければ最強にセキュアなアカウントにはなりません。

Security Groupは不用意に公開されていないか？
CloudFrontはOAIを利用しているか？
Lambdaは外部から実行できないか？

などなど、これらを継続的に確認していく必要があります。

つまり、

最強にセキュアなAWSアカウントを作る＝継続的にセキュアな状態を組織で維持する仕組みを作る＝ セキュリティ運用設計

ということです。

＝ セキュリティ運用設計

ということです。(大事なことなので2回書きました

「作る」と書かれているのに「結局運用の話なのかよ〜」と思ったそこのあなた、甘えないでください！

これは上級者を目指すセッションです。

上級者は、組織全体を巻き込んで、すべてのAWS利用者がセキュリティを意識してセキュアな環境が自動的に維持される文化を作るべし、です。

上級者は巻き込むことが仕事ですよ！

というわけでこのセッションでは最初に行うAWSのセキュリティ確保の設定とその展開方法についてさらっと押さえて、本題のどのように運用の仕組みを作っていくか、という流れで話していきます。

ちなみに、今回のセッションフォーカスは結構狭めのAWSセキュリティについてですが、より幅広いAWSセキュリティについては昨年登壇した下記ブログを見ていただくといいでしょう。

1. セキュアなアカウント単体の原理

AWSアカウントをセキュアにしていくためにやれることは沢山あります。

よくあるAWSのセキュリティ対策初期段階の悩みはどこから対策していけばいいか？というものです。

これを解決するのはAWS Security Hubを利用してAWS環境のセキュリティチェックを行い、セキュリティベースラインを作っていく手法です。

詳細は下記セミナーでも話しており、同じような内容は他にもいろんなブログでちらほら書いていますので、ここではサラッとだけ説明します。

AWS Security Hubはセキュリティ基準(スタンダード)というAWS環境のセキュリティチェック機能を持っており、この基準のうち「AWS基礎セキュリティベストプラクティス」は非常に汎用性の高いチェックツールになっています。下記のような直感的なスコア表示が嬉しいです。

例えば以下のように適切な設定ができているかチェックしてくれます。

Security GroupのSSHポートが開放されていないか
CloudTrailで証跡が有効になっているか
ルートユーザーにアクセスキーが存在していないか
S3バケットが公開されていないか
GuardDutyを有効化しているか

AWS基礎セキュリティベストプラクティスに沿って設定を強化していけば、セキュアなAWS環境が実現できます。また、幅広く存在するAWSサービスの利用に際してどのような点に注意すればいいか、学習できるという効果もあります。そのため、AWSを利用するすべてのユーザーがこのチェック内容をチェックし、対応できるといいでしょう。

AWS基礎セキュリティベストプラクティスのユーザーガイドには日本語で丁寧に、そのチェック項目がどのような観点でチェックされていて、どう修正したらいいかレコメンドがありますので、こちらも理解の助けになります。

これは宣伝でもありますが、クラスメソッドではこれを応用したセキュアアカウントという仕組みを提供しており、下記ブログで詳細に解説しています。この中でも同じ仕組みを利用してセキュアに保つよう設計されています。クラスメソッドのお客様は是非積極的にこちらを利用して頂き、直接クラスメソッドのサービスを受けていない方も是非まねしてください。

ざっくりと以下のような構成になっています。

各コンポーネント毎細かい解説もありますが、上記ブログを参照してください。ここでは割愛します。

「1. セキュアなアカウント単体の原理」のまとめとしては、とにかくSecurity Hubを利用してAWS環境のセキュリティを強化することと、AWSアカウント作成時にこれをうまく実現していく方法が必要になるよ、ということです。

2. ベンディングマシンとアカウント運用

そこで必要になるのがベンディングマシンです。

ベンディングマシンとは、新規のAWSアカウントを生成・セットアップする仕組みの概念です。単一の機能を指す言葉でがありません。ベンディングマシンの役割としては、必須のサービスを有効化したり、ベースラインの環境を構築したりします。

例えば、始めから有効化すべきサービスであるCloudTrailやAWS Configなどを有効化したり、自社に必要なIAMの設定を行ったりと、自分たちに合わせた設定を行うものです。

実現方法は様々あり、特にこうすべき、というものはありません。下記のような手法を自社環境に合わせて検討・採用しましょう。

CloudFormation StackSets
Terraform
AWS Organizations
AWS Control Tower
などなど

それぞれの手法を軽く説明します。

CloudFormation StackSetsは複数のリージョンやAWSアカウントに対して一括でCloudFormationを展開する機能です。AWS Organizationsと連携して非常にかんたんに全体へ展開する機能もありますが、AWS Organizationsを利用しなくてもStackSetsの機能を利用できることがメリットの1つです。

こちらに詳細があります。

IAM RoleによるStackSets利用をする場合には、下記も一緒にご利用ください。

TerraformはAWS環境でIaC(Infrastructure as Code)を実現するためのサードパーティのツールです。CloudFormationに依存せず、冪等性を意識しながらインフラの管理が可能です。

Terraformを利用したベンディングマシンは下記のVisional様の事例が参考になります。

この内容の参考ブログは以下です。

AWSでマルチアカウントの管理を実現するサービスとしてはAWS Organizationsがあります。

AWS Organizationsについては以下のブログもどうぞ。

AWS Organizationsは以下のような各種AWSサービスと連携して、マルチアカウント管理の機能を発揮します。

AWS SSO
CloudFormation StackSets
GuardDuty
Security Hub
Systems Manager
CloudTrail
Config
などなど

AWS Organizationsはマルチアカウント管理を行う際のメリットは多いですが、契約状況などで利用に制約がある場合もありますので気をつけてください。

ただ、連携できると言うだけで直接ベンディングマシンの機能を持ち合わせているわけではありません。主にCloudFormation StackSetsの機能を利用してベンディングマシンを自前で実装していく必要があります。

AWS Control TowerはまさにAWS Organizationsを利用してベンディングマシンを実現する手段の1つです。AWS Control Towerはベンディングマシンも含め、AWSマルチアカウント管理を実現するために必要な様々な機能を有し、Landing Zoneとして機能します。Landing ZoneはAWSマルチアカウント管理におけるベストプラクティスの概念です。

AWS Control Towerを有効化すると、ベンディングマシン以外にも、ガードレールやログ収集基盤、ID集約などが行われ、よりベストプラクティスに沿ったLanding Zoneが簡単に実現できます。下記のような構成になります。

反面、Control Towerで実現する設計に従う形になるので自由度は下がります。一度トライアルしてみて、自分たちに合うか確認するのもいいでしょう。

最近のControl Tower事情については下記にまとまっていますのでご確認ください。

また、ベンディングマシンを拡張するためのソリューションとしてCDKを利用して拡張するものと、Terraform(AFT)を利用して拡張するものもあるのでこれらも参考にすると、より自分たちにあったベンディングマシンの構築が簡単になります。

様々な仕組みでベンディングマシンを実現できますが、大事な観点を1つ補足します。

これらの仕組みはAWSアカウントを作成したときだけではなく、継続的な変更にも適用していく必要があります。AWSのサービスは日々変わっていきますので、これに合わせて新しい機能を有効化したり、あるいはIAMポリシーを変更したりとベースラインを変更維持していく運用が発生します。

こういった維持運用はCloudFormationのUpdate Stackを利用することで更新していくのも1つの方法ですが、これはCloudFormation未対応のリソースには適用できないというハマりポイントがあります。たとえはSecurity Hubのセキュリティ基準内の各コントロール(チェックルール)の調整は2022/07/26現在でCloudFormationで未対応のリソースです。

各AWSアカウントにメンテナンス用のIAM Roleを展開しておき、スクリプトを流し込めるようにしておくなど、柔軟に運用できる仕組みも検討しましょう。

ちなみにSecurity Hubのコントロール設定はSecurity Hubの親子関係を利用しても同様に管理できないため、注意しましょう。こちらのドキュメントに詳細があります。

「2. ベンディングマシンとアカウント運用」をまとめると、何でもいいからまずベンディングマシンを用意して、それを維持する仕組みを作っていきましょう、ということです。

使い続けるものですから、その時の状況に合わせて選択をし、時には切り替えて行くことになりますので、自分たちの選択できる、使いやすい、文化にあったものを利用してください。選定時の最後のひと押しは「あとから変えることになってもいいや」という気持ちだと思います。

3. 最強にセキュアな運用

さてここからが本題です。

最強にセキュアな運用を考えていきたいわけですが、このセッションあるいはブログ記事を見ている方々は、それぞれ利用できるAWSサービスも使うツールもAWSアカウントの数も満たしたい基準もみんな違います。

ここで始めの方の言葉を引用します。

セッションのテーマは「自分たちの最強のAWS環境を作ろう」です。

世の中にある「こうやるとセキュアになるよ」という情報を適用していけば勝手にAWS環境がセキュアになるわけではありません。

自分たちの環境・自分たちの要件に合わせたAWS環境のセキュリティを維持運用する仕組みを作り、これを回しながら継続的に取り組み続けることで初めて最強にセキュアなAWS環境を実現できます。というわけで世の中の情報は参考になりますが、皆さんは上級者としてこれらの情報を自分たちの環境ではどうするか、という観点で捉えて運用設計に役立ててください。

この章では実際に私が実施している実装と周りの巻き込み方について紹介しますので、参考にしていただければと思います。

実装アーキテクチャ1: Security Hub集約とコンプライアンス違反Slack通知

以下要件の実装例です。

管理スコープ
- 社内のAWSアカウントすべて
  - かなり広い！
- 本番用もあれば検証用もある
  - 顧客向けサービスもあれば、個人の検証用もある
管理条件
- AWS Organizationsは利用しない
  - 適用範囲が幅広く多数のAWS Organizationsをまたぐため
- 管理対象の自由度を確保する
  - スコープの広さに合わせて制約を小さくする
- Security Hubの集約はできる
  - 流石にこれがないと何もできないのでAWS Organizationsを利用しない集約を実施

この要件を下記アーキテクチャで実現します。

Security HubはAWSアカウント単位でリージョン集約を行います。これを東京リージョンで行い、東京リージョンのSecurity HubをOrganizationsを利用しないでinviteして集約します。以前はSecurity Hub自体でリージョン集約ができなかったため全リージョンで集約を入れていましたが、現在はこれだけで済むようになりました。

ベンディングマシンにて集約を行う設定を入れつつ、ついでに必要最低限のコントロール無効化を行います。IAM.6やEC2.8などの自社で必要ないもの、管理が煩雑で全体に適用しないものは無効化していきます。

新規のAWSアカウント作成依頼を受け取る際に、AWSアカウントの担当者のSlackIDを収集しておき、各AWSアカウントの識別しやすい名前とアカウント種別と合わせてDynamoDBに登録します。これはSecurity Hubのチェックで違反がある場合に担当者にメンションする際に利用します。ポイントとしてはDMしないことです。閉じた1人に通知するより、関係者の目の届くところで通知し、他のメンバーにも注意を促す方が建設的です。

要件に合わせていくつか設計の観点を整理します。

まずアカウントの種類を下記2種類に分類しました。

本番環境以外
- 外部提供するプロダクトの開発・検証環境
- 社内の個人検証環境
本番環境
- 外部提供するプロダクトの本番環境

あまり細かく分類しても大して違いがなかったのでこのようにしました。

続いてSecurity Hubの各コントロールの対応方針を3種類策定しました。

是正まで追跡
- 検知項目が是正されるまで全体の管理者が追跡する
- 7日以内の修正目標
通知のみ
- ユーザーに通知のみ、是正するかは任せる
- 通知したら抑制済みとし、セキュリティスコア対象外
対応しない
- 対応する必要なし、抑制済みにする

今回は個別システムに対するセキュリティチェックの設計を行っているわけではありませんので、本当に危ないものだけ全体で管理し、それ以外はやってもやらなくてもいいよ、くらいの度合いに設定をしました。

コントロールはある程度パターンが有り分類できましたので下記のように分類を決めました。

必須サービス・設定
- 必須で有効化すべきサービスや必要な設定
- サービスや設定毎の特徴があるため実際はまとめて分類できない物が多い
可用性確保
- マルチAZやバックアップなど
- セキュリティといえばセキュリティだが、今回のスコープでは特に幅の広い要素
ロギング
- 各種サービスのログ保存など
通信中の暗号化
- TLSを利用するもの
保管時の暗号化
- KMSなどを利用したストレージ上の暗号化

これを合わせて、AWSアカウントの種類とコントロールの分類に対するその対応方針を当てはめた図がこちらです。

分類/アカウント種類	本番	本番環境以外	備考
必須サービス・設定	是正まで追跡 (基本的に)	是正まで追跡 (基本的に)	実際はコントロール個別での判断が多い
可用性確保	対応しない	対応しない	厳密なセキュリティ要件ではないため管轄外
ロギング	是正まで追跡	対応しない	本番環境は大体のログは必須とする
通信中の暗号化	是正まで追跡	是正まで追跡	現代のインターネットでは必須
保管時の暗号化	対応しない	対応しない	ポリシーと規制要件のためここでは管轄外

ざっくりとコントロールの分類としては上記になりますが、他にも検討した内容のメモを以下に貼ります。

運用上煩わしいものは対応しない
- VPCフローログとか
WAF適用は本番で通知のみ
- WAFが不要な対象もあるため
OS以上のレイヤーの脆弱性管理は管轄外
- SSMパッチコンプライアンスなど、別で管理する場合も多いため

このような分類手法は他の環境でも応用できそうだと思ったので、是非活用してみてください。

実装アーキテクチャ2: 是正までの追跡方法

Security Hubのセキュリティチェックにより出てくる検知をFindingsといいますが、このFindingsが適切に是正されたか、というステータスをトラッキングすることはけっこう大変です。

例えば、このFindingsのIDを検知時にDynamoDBに保存しておき、一定時間経過後にこれを取り出して是正済みか確認する手法を検討します。ソートキーに検知日時を入れてデイリーでFindings一覧を収集してすべてのステータスを確認する実装とします。この場合、パーティションキーがほぼ固定になり分散されないバランスの悪いテーブルになります。さらに、Security HubのFindingsのステータスを確認するAPIはGetFindingsですが、これでFindingsIDを指定して回すのは20個ずつの制限がありチェック負荷は大きいです。

そんな悩みもあり、私は無理に頑張る必要ないな、と思いました。

Security Hubには下記のようにセキュリティスコアを直感的にわかりやすく確認できる機能があります。

この画面でスコアが100%になるように運用する、というわかりやすく簡単な方針にしました。

頑張って自分たちの要件に合わせた実装をしていくことも大事ですが、AWSのサービス自体常に変わっていきます。適度に頑張らないでSecurity Hubに任せるなど、頑張らないことも同じように大事でしょう。

この方針に合わせて、Findingsが検知された際の処理方法を、StepFunctionsを利用して下記のように実施すると定義しました。

コントロール単位の対応方針をDynamoDBの対応方針テーブルに入れておき、これをベースに3種類の対応方針毎にフローを分岐、本当に対応すべきもの以外はステータスをすぐに抑制済みに変えて、Security Hubのスコア算出から除外するようにしました。これで対応すべき内容のみ画面上に出てくるようになります。

周りの巻き込み方1: セキュリティスコアの全体通知

AWS環境全体のセキュリティを維持向上するためには、すべてのAWSユーザーの協力が不可欠です。周りのみんなを巻き込むにはモチベーションをアップする仕組みが必要です。

例えばセキュリティスコアのランキングを定期的に通知する、という手法が考えられます。

しかし、残念ながらAWSマネジメントコンソール上で確認できるSecurity Hubのセキュリティスコアは、APIで直接取得ができません。というわけで、無理やりスコアを算出する仕組みを作りました。(こういうところは無駄に頑張るたくなります)

これを応用して以下のように通知できます。

大事なところとしては、スコアが低い順じゃなくて、高い順にすることです。あくまでモチベーションを上げるためですので、ポジティブなランキングが好ましいでしょう。

また、是正されてスコアが100%になったら盛大に祝うのもありです。下記のようになります。

Slackでリアクションがたくさん付くと嬉しいですよね。

周りの巻き込み方2: 具体的なアクションをリクエストする通知

違反の是正を依頼する際も、丸投げはよくありません。

基本的に全体のセキュリティを管理する側はAWSについて熟知し、ベストプラクティスやどうすべきかというコツを知っている立場です。各メンバーより詳しい立場ですから、是正を依頼する通知は具体的に、すぐに次の行動がわかるような通知を心がけましょう。通知メッセージの設計時は以下のような観点を確認してください。

いつまでに対応すればいいか
どの程度重要か(高中低)
何を判断すればいいか
どのアカウント/リソースか
対応方法は

例えば以下のような通知になります。

タイトル: [重要度: 高]外部から制限なくSSHでアクセス可能なSecurity Groupが検知されました
対応目安: 24時間以内に対応してください
確認内容: アタッチされているリソースに対するSSHを誰が利用しているか確認してください
対象
- AWSアカウント: AAA Project Prod (999999999999)
- リージョン: ap-northeast-1
- リソース: test-sg
想定外の設定の場合、SSHのポートを特定IPのみに絞るか、閉じてください。Systems Manager Session Managerを利用することでポートを閉じたままシェルを利用することも可能です。<参考URL>
許容すべき設定の場合はこのスレッドでメンションをつけて理由を説明してください。

メッセージはしっかり作り込み、メンバーが判断に迷うことや追加の質問をすることが無いようにしましょう。

「3. 最強にセキュアな運用」をまとめると、自分たちのSecurity Hub管理のスコープや要件を定義し、どこまで自分たちで実装するのか、どこまで任せるのかを決めていきます。どうせ運用しながら変えていくので、「簡単なところから着手する」とか、「Security Hubの機能強化を待つ」とか割り切るところは割り切って進めましょう。(AWSへのフィードバックや機能リクエストもお忘れなく！)

そして、周りのみんなを巻き込めるようにポジティブに！とにかくポジティブにいい雰囲気を作りましょう。逆にネガティブになりがちな是正依頼の通知は丁寧にしましょう。