こんばんは（？）、セキュリティエンジニアリングの西川です。
re:Invent始まりましたね。 カミナシからも今年は4名参加して、AWSの知識・技術向上のためさまざまなセッションに参加しています。
私は今回re:Inventは初参加で、右も左もわからない状態ですが、その中でも特に楽しみにしていたセッションがありまして、それが「COP402: Coding for compliance at scale」でした。
このセッションはレベルが400（Expert）という一番高いものでしたが、コードを見ながら解説がされていくため元々開発者だった私にとっては非常にわかりやすかったのと、 RDK（AWS Config Rule Development Kit）を試そうとして色々と調べていたので、英語はあまり得意ではないのですが理解することができました。
AWS Configのカスタムルールが書けるのはみなさんご存知かと思いますが、 実際どう書いたらよいの？は情報があまりなくて、私自身使いたい！けど使えないという状態でした。
ということで、それを今回はCode Talkというセッション形式で、コードを見ながらデモンストレーションを通して学べたので、 今日はまずはどういう使い方ができるのか？という概要を共有したいと思います。
そもそもこのセッション自体は、ConfigのカスタムルールをRDKを利用して、AWS Configルールを作成しつつ、 そのルールに非準拠のものに対して、AWS Systems Managerのrunbookを使って修正していくというものでした。
弊社カミナシでは、セキュリティの文化の醸成ということがセキュリティエンジニアのミッションであるのと、つい先日、すべてのチームではないものの主要なチームとデリゲーションポーカー（https://nuworks.jp/ja/product/del-poker/）のようなものをして、 セキュリティの責任をどちらがどのぐらいまで持つかという話をしました。
そのためセキュリティエンジニアリングが勝手に開発チームのセキュリティを実装するということはしないのですが、 多くの企業では、このような仕組みはセキュリティチームが横断的に統制を整えていくような組織では非常に有用なサービスであると思います。 ただ、カミナシではそうではないので、やり方は考える必要があるもののとても使ってみたい技術の一つです。
RDKはpythonでコードを書いていきます。 今回のセッションでは、EBSの暗号化が無効だった場合に検知をする仕組みと、RDSのbinlog_cache_sizeが40000以外だった場合に検知するというもののデモンストレーションがまず行われました。
まず、pythonでAWSを操作するbotoライブラリを利用してリソースからjson形式のデータを取得して、それをコンプライアンスと比較して準拠しているのか検証します。 それが一つ目の話でした。 もう1つが、binglog_cache_sizeが40000以外だった場合に、AWS Systems Manager の runbookを用いて、remediationを実行しました。 今回はAWSのコンソールパネルから手動でremediationを実行しましたが、自動で修正するために、例えばコードパイプラインの中でコンプライアンスに準拠していないリソースを特定し、runbookを実行することで自動的にリソースを準拠させることもできます。
このセッションだけコードをみて、英語を聞いていくのに集中して一切写真を撮っていなかったのがものすごく悔やまれるのですが、概念や実際にコードを書いていく時間も含めて1時間も含まずこんな簡単に実装できるんだなーという驚きと、使ってみたいという気持ちが一層高まってきました。まだまだRDKを使った事例は少ないのでみなさまの組織でも利用して情報共有していきましょう！
私自身も情報共有していければと思っています！
それではまた何かおもしろい情報があればお伝えしたいと思います！
