プログラマでありたい

おっさんになっても、プログラマでありつづけたい

AWSのアカウントセキュリティ

 いま技術書典8に向けてAWSのアカウントセキュリティをテーマに執筆中です。(進捗1%)
執筆の元ネタと告知を兼ねて、私がAWSのセキュリティをどう捉えているか紹介します。

AWSのセキュリティの3要素

AWSのセキュリティをざっくり分類してと、次の3つで考えるのが良いと思います。

  • AWS上に構築するシステムのセキュリティ
  • AWSアカウント自体の管理(≒IAMの設計・運用)
  • AWSアカウントのガードレール設計

f:id:dkfj:20200108200235p:plain

 AWS上に構築するシステムのセキュリティについては、ネットワークであったりEC2やRDSなどを利用して構築したサーバ・ミドル・アプリなどがあります。マネージドサービスというAWSならではの要素がありますが、基本的な考え方は従来のオンプレと大きく変わらないと思っています。システムとして穴がない状態を、AWSを使ってどうやって実現するのかという問題です。
 次にAWSアカウント自体の管理です。これはほぼIAMの設計・運用に依存する部分が多いです。こちらについては技術書典7で発表した『AWSの薄い本 IAMのマニアックな話』の中心テーマです。ここでは割愛します。
 最後のAWSアカウントのガードレール設計。この言葉だけ読んでもピンとこない人が大半だと思います。IAMの設計はAWSアカウントのセキュリティの大部分を担いますが、運用しているうちに抜け漏れが出てきたり、あるいはカバーしきれない部分があったりします。またAWSアカウントが適切な状態で運用されているのか、或いは危険な状態にあるのか可視化していないと適切な判断ができません。それらの予防・検知するための施策が、ガードレール設計です。

 今書こうとしている本は、この3つ目のAWSアカウントのガードレール設計をメインのテーマとしています。

AWSアカウントセキュリティとマルチアカウント管理

 そもそもこのガードレール設計というのがどこから来ているかというと、AWS Control Towerです。このサービスは、複数アカウント環境をセキュアに設定、管理するためのサービスです。これ使えよという話ではあるのですが、現状では新規のアカウント対象かつマルチアカウント前提という形になります。AWSのアカウントセキュリティは万人が必要だと思うものの、この前提だと敷居が高いのも事実です。ですので、Control Towerの機能の中心にあるガードレールやランディングゾーンを紐解いて、AWSアカウントのセキュリティを保つためには何が必要で、どういう設計・設定をすればよいのかを抽出しようと思います。その考え方を用いて、1アカウントにも適用できるようにパターン化を目指しています。

 一方で、マルチアカウント管理のニーズも高く、どうすればよいのかまとめる必要もあります。分量も多くなることもあり、かつ私のリソースも足りないので技術書典8ではすっぱり諦めます。その次のテーマとして必ず書きたい内容なので、(当選するか解らないですが)技術書典9で出すことにします。当選しなくても、とにかく書いて頒布します。今年は3回も技術書典があることですし。ということで、IAMから始まるAWSのセキュリティ3部作という形でまとめる予定です。


ガードレール設計って何?

 ここまで読んでいる人は、じゃぁガードレール設計って具体的になりするのと思っていると思います。今、必要と考えているのは、大まかにいうと下記の事項です。

  • 操作履歴の記録・通知
  • 定点・イベント発生時にAWSの状態を記録し、違反がないかのチェック
  • 脅威の検出・通知
  • 上記アラートの一元管理
  • コスト最適化

 これをAWSのサービスに当てはめると、それぞれCloudTrail, Config, GuardDuty, SecurityHub, Trusted Advisorになります。じゃぁそのサービスを入れればいいじゃんとなりがちですが、そもそもの導入の目的を整理しておかないと実際はせっかくの機能も有効活用できていないとなりがちになります。そこを整理した上で、具体的な設定までのガイド的な本になれればと願っています。

まとめ

 構想はあれど、筆が進んでいないです。神頼みをやめて、愚直にやっていくこととします。これ以外にも、全く別の商業誌も執筆中だったりします。何とかなる?

booth.pm