おはようございます（？）セキュリティエンジニアリングの西川です。
AWS re:Invent 2023 2本目の記事です。前回同様、若干ガバナンス系の話なのですが、 「SEC319-R | Enhance cloud security: Using AWS SRA with Terraform」というセッションを聞いていました。
このセッションではChalk talk というセッション形式で、SRA（Security Reference Architecture）の概念やこういう風に適用していくといいよという話をスピーカーがしながら、参加者は適宜質問をするという形式のもので、スピーカーの方から「これは対話形式なので質問があれば挙手をお願いします」と伝えていました。
SRAという言葉はまだあまり聴きなれない方も多いかもしれませんが、2021年あたりから出てきたもので、CIS Critical Security Controls や CAF（The Cyber Assessment Framework 「カフ」と発音します）というのをイギリスのNCSC（National Cyber Security Centre）が出していて、 それにもサイバーの資産管理どうしていくと良いのという話が出てきていてAWS SRA(https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html)も関連しています。
今回のAWS SRAの話ではControl Towerを使ってもGuardDutyやSecurity HubやGuardDutyのリージョン管理とか、GuardDutyのEKS Protectionは自動で有効にならないので、 手動でやってしまうと後々管理が難しくなるよねというところで、「Terraform コードで管理していきましょう」というのが主題です、、と西川は理解していますが、間違っている可能性もあります。。
これに関しても前回記事と同様セキュリティチームが横断して統制を整えていく場合にはよいと思いますし、 一部統制を効かせるみたいな使い方はできるのかなーと思いますが、その匙加減が難しいと感じています。
ただ、上記のような考え方の企業は多くはないと思うので有用なものだと感じています。 カミナシではどうなのかというと、例えば開発チーム自身がEKS Protectionを有効にしよう！（※カミナシはEKSは使っていません）と言ってGuardDutyのEKS Protectionを有効化するのが好ましく、 セキュリティチームがそれを勝手に有効化するということはしません。やるとしても合意をとってお互いが納得をしてやるというのが最低限の約束です。
そういったこともありどこまで使えるかは考えながらやっていかなければいけないのですが、 こうやってコードで統制ができるのはガバナンスという観点では嬉しいですよね。
SRAが必要な理由として、今まで以上にクラウド導入の機運が高まっているということ、それにともなって、既存のオンプレ環境からクラウドに移行する際には、セキュリティが最重要となっているということがあり、だいぶ簡略化するとSRAで解決していきましょうという話でした。
今現在SRAを実践している人は私が見える限りで数名しかおらず、今後増えていくのかなと個人的には思っています。
実際かなり詳細な議論もしていたのですが、英語が難しくついていけなかったのと、ブログにするにはなかなか難しかったので省略していますが、とても面白かったです。
引き続き情報発信できるようにがんばります！
