いま技術書典８に向けてAWSのアカウントセキュリティをテーマに執筆中です。（進捗1%）
執筆の元ネタと告知を兼ねて、私がAWSのセキュリティをどう捉えているか紹介します。
AWSのセキュリティの３要素
AWSのセキュリティをざっくり分類してと、次の３つで考えるのが良いと思います。
- AWS上に構築するシステムのセキュリティ
- AWSアカウント自体の管理（≒IAMの設計・運用）
- AWSアカウントのガードレール設計
AWS上に構築するシステムのセキュリティについては、ネットワークであったりEC2やRDSなどを利用して構築したサーバ・ミドル・アプリなどがあります。マネージドサービスというAWSならではの要素がありますが、基本的な考え方は従来のオンプレと大きく変わらないと思っています。システムとして穴がない状態を、AWSを使ってどうやって実現するのかという問題です。
次にAWSアカウント自体の管理です。これはほぼIAMの設計・運用に依存する部分が多いです。こちらについては技術書典7で発表した『AWSの薄い本 IAMのマニアックな話』の中心テーマです。ここでは割愛します。
最後のAWSアカウントのガードレール設計。この言葉だけ読んでもピンとこない人が大半だと思います。IAMの設計はAWSアカウントのセキュリティの大部分を担いますが、運用しているうちに抜け漏れが出てきたり、あるいはカバーしきれない部分があったりします。またAWSアカウントが適切な状態で運用されているのか、或いは危険な状態にあるのか可視化していないと適切な判断ができません。それらの予防・検知するための施策が、ガードレール設計です。
今書こうとしている本は、この３つ目のAWSアカウントのガードレール設計をメインのテーマとしています。
AWSアカウントセキュリティとマルチアカウント管理
そもそもこのガードレール設計というのがどこから来ているかというと、AWS Control Towerです。このサービスは、複数アカウント環境をセキュアに設定、管理するためのサービスです。これ使えよという話ではあるのですが、現状では新規のアカウント対象かつマルチアカウント前提という形になります。AWSのアカウントセキュリティは万人が必要だと思うものの、この前提だと敷居が高いのも事実です。ですので、Control Towerの機能の中心にあるガードレールやランディングゾーンを紐解いて、AWSアカウントのセキュリティを保つためには何が必要で、どういう設計・設定をすればよいのかを抽出しようと思います。その考え方を用いて、１アカウントにも適用できるようにパターン化を目指しています。
一方で、マルチアカウント管理のニーズも高く、どうすればよいのかまとめる必要もあります。分量も多くなることもあり、かつ私のリソースも足りないので技術書典8ではすっぱり諦めます。その次のテーマとして必ず書きたい内容なので、（当選するか解らないですが）技術書典9で出すことにします。当選しなくても、とにかく書いて頒布します。今年は３回も技術書典があることですし。ということで、IAMから始まるAWSのセキュリティ３部作という形でまとめる予定です。
なお2020年の技術書典はイレギュラーで【年3回開催】となります。（オリンピックに伴い、各種大規模イベントが玉突き移動して広い会場の確保が難しくなったため）
— 技術書典公式アカウント (@techbookfest) 2019年12月25日
・技術書典8（2月29日/3月1日の2days）
・技術書典9（7月）
・技術書典10（11月）
スポンサー募集はこちら📚https://t.co/5IE4IjNQ1X
ガードレール設計って何？
ここまで読んでいる人は、じゃぁガードレール設計って具体的になりするのと思っていると思います。今、必要と考えているのは、大まかにいうと下記の事項です。
- 操作履歴の記録・通知
- 定点・イベント発生時にAWSの状態を記録し、違反がないかのチェック
- 脅威の検出・通知
- 上記アラートの一元管理
- コスト最適化
これをAWSのサービスに当てはめると、それぞれCloudTrail, Config, GuardDuty, SecurityHub, Trusted Advisorになります。じゃぁそのサービスを入れればいいじゃんとなりがちですが、そもそもの導入の目的を整理しておかないと実際はせっかくの機能も有効活用できていないとなりがちになります。そこを整理した上で、具体的な設定までのガイド的な本になれればと願っています。
