はじめに
Septeni Japan株式会社でプロダクト開発&インフラセキュリティ対策を行っている市原と申します。
この記事は、社内のプロダクトに対してセキュリティのガバナンスを効かせる為にAWS Control Towerを導入した話となります。
Control Tower導入の話は下記のパートに分かれて記事を執筆しています。
今回は概要編となります。
背景
当社では、AWSを活用してプロダクトを多数開発しています。
プロダクトの管理方法については、プロダクト規模の大小、または、開発を行う組織も内製･グループ会社と様々な状況で行っており、セキュリティチェックに対しては、グループシステムセキュリティ管理規程と呼ばれる独自のチェックを行ってからリリースを行っていました。
概要
インフラチームが主体となり、セキュリティ向上のためにControlTowerを利用してガードレール（予防的ガードレール、発見的ガードレール）を構築しました。
リスクのある操作を禁止する（予防的ガードレール）
Root権限でも変更できない状況を作り出し、乗っ取られても何もできない状況を作ることでリスクを回避する
高リスクの設定や外部からの脅威を発見する（発見的ガードレール）
開発における自由度と外部脅威への対策をバランスする為に、設定変更を発見することで、意図して設定しているか否かを確認できる状況を作る
ControlTowerを採用した理由
- ガードレール設定（後述）は手組みすることも可能だが、ControlTowerを利用することで一括で実装が可能となっている為
- 当社独自のルールに関してもコントロールタワーの基盤上で追加実装が可能な柔軟性も備えている為
プロダクトチームとの関係性
ガチガチにルールを設定するよりも、開発の自由度とセキュリティのガバナンスをトレードオンしていきたいと考えています。
セキュリティを高水準に保つためには権限を極力絞った形での運用が望ましいですが、そうしてしまうと現実では、都度権限を付与するなどの作業が増加してしまったり、その作業のために開発がストップしてしまったりという好ましくない業務が発生してしまう可能性が十分に考えられます。
なので開発チームには、設計時からセキュリティに対しての意識を持ってもらい、セキュリティ意識や対策スキルの向上を目指し、一緒に解決していきたいと考えています。
具体的にはリスクある設定が発見された際に、｢このままで良い｣と判断する場合においては、インフラチームにその理由を伝えてもらい、問題ないか議論する機会を設けることとしています。
導入の難所
制御や検出の項目は一つずつ精査していきましたが、すべてのアカウントに対して一度で適用すると管理しきれない為、テストアカウントや影響の少ないプロダクトから試験導入をしました。
同様に、SecurityHubのコントロールも一度にすべてのコントロールを適用すると管理しきれない為、重大度で分けて、段階的に導入していきました。(現状、重大度:重大と大が有効になっている状態)
一方、重要を適用し、大を適用したタイミングで、なぜかすべてのコントロールが有効になってしまい、大量に検出が上がってしまいました。
これは、SecurityHubのバグなのかどうかはわかりませんが、何度行っても同様に大量に検出が上がってしまう為、これについては通知システムをOFFにし、上がってしまう検出については無視するという対処を現在もしています。
次回
今回はControl Tower導入の背景などをお話しましたが、次回はいよいよControl Towerの機能を紹介しつつ、導入した機能などを紹介していきます。
Discussion