AWSのセキュリティ関連知識の復習のため、AWS認定 セキュリティ-専門知識を読んだときのメモ。
セキュリティ意識の高まり
数年前は影が薄かったセキュリティ用のサービスも、今や使って当然のものになりつつある。昔はCloudTrailとConfigさえも恐る恐るそっと提案せねばならなかったりしたものだが、今ではそれらはもちろん、GuardDutyやWAFなどもむしろ使った経験がないのはいかがなものかくらいの重要な扱いを受けている印象がある。いいことである。
CloudTrail, Config, GuardDuryなど、とりあえず有効化しておけばいい類のサービスは、時間を見てひとまとめにし、Terraformで一式作れるようにしておいてもいいかもしれない。
相変わらず敷居は高い
一方でセキュリティ向けのサービスはいずれも敷居が高い。その前提となっている考え方をわかっていないと、なにをどこまですればいいのか検討さえつかない。NIST サイバーセキュリティ フレームワーク (CSF) AWS クラウドにおける NIST CSF への準拠として公開されているが――ちなみにIPAがFramework for Improving Critical Infrastructure Cybersecurity 重要インフラのサイバーセキュリティを 改善するためのフレームワークとして対訳を公開してくれている――どちらかというとマイナーな資料なのではないか。実際の開発現場は、動くものを作るのに精一杯で、セキュリティまで手が回らない（手だけでなく、頭もお金も）ことがしばしばだから、無理もないことだが、このあたりを上手くまとめつつ関係者各位に説明できるスキルが重要だろう。自分がちゃんと説明できるくらい理解しておくのは大前提として。
高まる管理コストにどう対応するか？
またセキュリティ系のサービスは管理コストもなかなかのものがある。セキュリティ専門のエンジニアがつける大規模プロジェクトや、または金融系のようにセキュリティリスクの高さが段違いのプロジェクトは、おそらくセキュリティのためのコストにも理解があると思われるからまだいいかもしれない。だが、そうでない開発プロジェクトだと、セキュリティのために乏しい予算と人的リソースを身を切る思いで（しぶしぶ）出しているのが実情ということもあろう。
が、そうはいっても、そのようなプロジェクトにおいてもセキュリティをないがしろにするわけにもいかない。
そんな場合は、なるべくそもそも守るものを減らすアーキテクチャや運用方式を選択するのが良い工夫であるように思われる。たとえばマネージドなサービスを活かしてEC2を自前で運用するのを極力避ければ、それだけセキュリティ監査のための工数は大きく減るだろう。また直接の手オペを減らしてなるべくツール化または完全自動化し、メンバーに渡す権限を限定したほうが、大きな権限を渡したメンバーの管理に気を遣うよりも安く上がるのではないか。守るものが少なければ、必要な気遣いも少なくて済む。
