AWSをはじめとするクラウドプラットフォームの普及に伴い、DevとOpsの境目はかなり曖昧になっています。その中でもIAMの管理は設定によっては権限昇格を引き起こしかねないことから、その管理権限は慎重な管理になりがちです。結果的に、IAMは属人的な管理を行っている組織が多いのではないでしょうか。
一方で、DevとOpsの境目がどんどん曖昧になっていく中で、IAMロールやIAMユーザーを自由に作りにくい状況があると大変不便です。IAM関係のトライ・アンド・エラーが手軽に行えないことから、開発速度の鈍化を引き起こしたり、アーキテクチャ設計の上で運用上の足かせとなったりといったことが起こります。
また、それらの問題を回避しようとした結果として、IAMロールやIAMユーザーの使い回しが横行しはじめるなど、結果的に最小権限の原則が守られなくなっていくことも少なくはないのではないでしょうか。最小権限の原則が守られないと、脆弱性がシステムにもたらす影響を思わぬ所で広げかねないリスクがあるため、徹底していきたいと考える組織も多いかと思います。
しかし、やはり増え続けるIAMロールやIAMユーザーに対して属人的な管理体制はスケールしにくく、簡単にこれらを解決することはできません。主な原因は、IAMが属人的な管理をなされていることによってIAMロールやIAMユーザーを自由に作りにくい状況にあります。
では、どうしたら良いのでしょうか?IAMの管理を個人のものではなくチームのものとしていき、かつセキュアにそれを扱うためには何が必要でしょうか?
本セッションではAWS IAMの管理において、それをIAM管理担当者の属人的な管理を行っていたところから脱却し、Github上でIAMリソースを安全に管理するスタイルに行き着くまでに感じた課題とその解決手段について話します。
キーワード:
- IAM Policy
- Permissions Boundary
- Infrastructure as Code
- CI/CD