aws-dev-live-show.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
クラウドを上手に活用していくうえで、セキュリティを考慮したインフラの構成や設定がより重要になります。Infrastructure as Code (IaC) は、クラウドリソースの設定をデプロイ前にチェックしたり、データの機密性に応じて環境を分離したりを容易にすることで、セキュリティの運用を楽にできます。
一方、IaC そのもののセキュリティも気になるところではないでしょうか。たとえば、「IaC における最小権限の原則って実際どうなの ?」など、気になるトピックについてセキュリティと DevSecOps のスペシャリストとディスカッションしながら、IaC を使って「楽してセキュアに」する方法を一緒に考えてみましょう !
会の様子
IaCとは
IaCの簡単な説明として、ブラックボックスになりがちかつミスがどうしても避けられない手動環境構築の問題を解決するプロセスであり、変更を透明化かつ自動化することでミスを減らすことができるという話がありました。
環境分離
IaCを使って環境複製を簡単にすることで、本番環境/サンドボックス環境を分離することができるという話がありました。(AWSアカウントに代表されるように独立した権限管理を行う)
また、Continuous Resilienceの考え方を適用しやすくなるということです。
一方でIaCを活用していても環境分離ができていないケース(開発環境のAWSリソースを本番環境のS3バケットに移動...)も多いという話がありました。
こういった環境分離ができていないケースでは、その後に「開発環境も本番環境同等のセキュリティレベルを担保しましょう」という話になってしまうリスクもあるため、一過性のものであっても非常に危険だということです。
自動化
IaCにおいてコード化することで、TrivyやAmazon CodeGuru Security*1をはじめとしたツールによる自動化が適用させやすくなるという話がありました。
ツールによる自動化をしていくことで、レビューガイドラインや完了の定義の整備ができていくうえに対面(対人)レビューにおける心理的負担を下げる*2ことにも繋がるため、楽にセキュリティを担保していく活動に繋がるということです。
また、AWSではAWS Well-Architected DevOps Guidlineにこういった取り組みのベストプラクティスを整理しているため、ぜひ読んでほしいということでした。
最小権限の原則
最小権限の原則はイメージ先行で考えられがちだという話がありました。(「最小」にしようという思考停止に走りがち)
最小権限の原則はシステム安定性の向上ソフトウェアデプロイの容易化などを目的としているものであり、真の最小権限の原則を適用することは不可能に近いということです。(最小権限の原則を本当の意味で実施ししようとすると運用は厳しくなる一方)
そのため、人に与える権限とリソースに与える権限は分けて考え、リソースに与える権限に関しては最小権限の原則を実践するようにすることが良いのではないか？ということです。(人に対しての権限は厳しすぎると作業中の差し戻しが難しい)
また、環境分離やコードレビューで万が一ミスをしても被害が最小限に抑えられている状態を担保しておくことで、ゆるめの権限設定をすることが許容されるケースも多くあるため、前述した環境分離や自動化とセットになる考え方だというのが重要だというお話でした。(IaCで環境複製が大変だと最大公約数的なRoleが作られがちになってしまう)
会全体を通した感想
話の音質もきれいで構成も丁寧だったので、非常に聞きやすかったです。
また、どの話でも共通して語られていた「楽をするためのセキュリティ運用」というテーマも開発者目線で非常に共感できるなあと思いながら聞いていました。
また、会の本題とは少しそれるのですが、最小権限の原則に関する相談がかなり多く関心を持たれている印象があるというのは意外だったので印象的な内容でした。
