AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策

　昨日の完成したぞエントリーに続き、『AWSの薄い本アカウントセキュリティのベーシック』関連のエントリーです。
f:id:dkfj:20200323084651j:plain

　私は今まで、あまりセキュリティって好きな分野では無かったです。もちろん必要性は解っていて、その対策等をいろいろ考えてはいたのですが、どこか自分の仕事じゃないなぁと思っていた部分があります。今回、AWSのアカウントセキュリティ本を書いて、ようやく腑に落ちました。それをまとめたのが、次のツィートです。

AWSのアカウントセキュリティ本書き終わって、今までセキュリティとか、その周辺の事項が好きじゃなかった。その理由が、ようやく確信に近いものを得た。あの領域の多くが、人間ではなくてコンピュータにやらした方が向いている。今まで解ってなかった
— Takuro SASAKI＠技術書典-1日目 (@dkfj) 2020年3月23日

24時間365日での自動攻撃。では、防御は？

　攻撃者が24時間365日、自動で攻撃してくる中で、それに対して防御する方が手動で対応するのはナンセンスということに気が付きました。もちろん、セキュリティの設計を考えたり、どういった判断をするかという部分で人間が果たすべき役割は大きいです。一方で、そのためのセキュリティの設定や、日々の攻撃に対する防御は人間に向いている仕事なのか？
　多分あまり向いていないのだと思います。セキュリティはどこか一箇所に不備があれば、そこを狙って侵入口をあけて、そこから内部に侵入される類のものです。人間が手動で設定していると、どこかでミスする可能性は高いです。EC2が登場したことにより、同じ設定をコピーして使うことが簡単に出来るようになりました。それ以来、一つ一つのインスタンスを設定して使う人は殆どいなくなり、職人が手を込めて作られて一台一台微妙に設定が異なる人間の温かみがあるサーバーはだいぶ減ったと思います。でもAWSのアカウントの設定という面ではどうか？一つ一つのアカウントごとに、まだまだ手動で設定されているのではないでしょうか？
　今回AWSのアカウントセキュリティ本を書きながら、AWSのサービスの最新の情報を学びました。もともとAWSでは、設定の大部分がCloudFormationなりCLIなりでコードから設定できます。そのうえで、そのコードをアカウントレベルでまとめて適用させる方法が整っています。つまりAWSではアカウント設定というレベルで、インスタンスと同じように同一の設定を簡単にできるようになっています。その手法について、ちょっと紹介してみます。

AWS Organizations × CloudFormation StackSetsの破壊力

　CloudFormationは、テンプレートを元にスタックを作成し、AWSを設定する機能です。その機能の拡張であるCloudFormation StackSetsは、複数のAWSアカウントやリージョンに対しスタックを作成し、一括で設定します。これだけでも充分便利な機能ですが、2020年2月にAWS Organizationsとの連携機能が発表され、ものすごい進化を遂げました。
　Organizations傘下で、アカウント作成・削除時、あるいは特定のOUに参加したタイミングで、自動でCloudFormation StackSetsを実行する機能です。

f:id:dkfj:20200324063218p:plain

　これがあれば、AWSのアカウント設定の自動化がものすごいレベルで進みます。具体的な使い方については、次回紹介しようと思います。
※本にも書いているので、気になる人はBOOTHへGo！！

まとめ

　セキュリティの施策で、設定レベルの作業は人類には向いていないので、テンプレート等を利用して自動化するべきです。AWSでは、そのためのサービスが凄い勢いで整備されてきています。特にAWS Organizations × CloudFormation StackSetsの組み合わせは破壊的です。この存在の有効性を確認できただけで、AWSのアカウントセキュリティ本を書いた意味があったなと実感するほどです。今、思っている事は以上です。

booth.pm