FLINTERS情シスの山本です。 ブログ祭りの企画で、今期の振り返りをテーマとして書くことになりました。
今期関わっていたプロジェクトのうち、主に関わっていた顧客のAWS環境にControl Towerの導入するプロジェクトについて書いてみようと思います。
AWS Control Tower とは - AWS Control Tower
Control Towerは一筋縄ではいかない
Control TowerはAWSのOrganization配下のAWSアカウントに対して、統合的な管理を行う仕組みです。
SecurityHub、AWS Configと連携したセキュリティポリシーの適用だけでなく、統合的な管理インタフェースを提供してくれるサービスです。
ただ、より高度な管理がしやすくなるためのサービスではあるのですが、現状ではまだ使い勝手としての評判はイマイチなように見受けられます。
Control Towerで横断的に管理が行えるものの、現状では一部のみ除外や変更などの例外対応を行うことがControlTower上では行いづらくなっています。
今回の導入に当たっても、当初の想定通りいかないことが多く、既存の運用と合わない部分など色々と問題がありました。
顧客の担当チームと連携してポリシーの選定、策定や、既存の稼働中のプロダクトに順次適用と進めていたのですが、検証環境ではすんなり行った設定では本番に適用できなかったりと。
最終的にControl Towerによる統制は行うものの、ポリシーの適用は限定的として、暫定的にSecurityHubやConfigは自前で管理することに落ち着きました。
Configは上手くやる必要がある
費用の問題としては、類にもれず本プロジェクトでもConfigの費用高騰が発生し、対策に奔走することになりました。
Configはリソースの変更記録を残すため、リソースが新規に作成される度にリソース用のログレコードが作成され、このログレコード数に対して課金されます。
とあるサービスでは、定期処理を行う際に自動でEC2インスタンスを複数作成、処理終了後に全部破棄するという、まさにクラウドという運用をやっており・・・。
定期処理が走る度にリソースのログレコードが大量に作成されてしまい、Configの料金が跳ね上がるという状態になっていました。
必要な時にサーバを立てて、要らなくなったら気軽に破棄できるというところがクラウド環境の利点ではあるのですが、そう簡単にはいかないようで。
セキュリティの面では確かに記録を残すべきではあるのですが、費用の問題ともトレードオフを考えた結果、手動で当該AWSアカウントのリソースをConfigの記録対象から除外するという対応になりました。
一部だけ除外する形にするために、Control Towerのカスタマイズを進められた顧客の担当チームの方には本当に頭が上がりません。
現在、顧客環境の全てのAWSアカウントに導入するという目標は無事クリアできました。
今後は検出されたセキュリティポリシー違反への対応体制の整備と自動化、セキュリティポリシーの高度化が目標になってきてます。
AWSの管理もプロダクトに負けてられない
AWSの統合管理は可能ならやるべきだと思いますが、なかなか大変ではありますね。
Control Towerだけでなく、各セキュリティ関連サービスについても組織内での統合管理を行えるようになってきてます。
Control Towerを使うだけでOKというわけではなく、プロダクト開発と同様に複数のサービスを組み合わせて目的の結果を得る、というのは統合管理も例外では無いみたいですね。
今後もAWSの管理のレベルを上げていきたいところです。
