こんにちは、クラウドセキュリティアーキテクトの大島悠司です。
7編にわたって、弊社ニューリジェンセキュリティ株式会社で実践している、「Change Managerによる変更管理と本番アクセス統制」について紹介したいと思います。
今回の「①動機づけ編」では、変更管理と本番アクセス統制の必要性について紹介します。
マルチアカウント構成とIAM設計
多くの企業ではワークロードの実装において、柔軟性や拡張性を強みとするクラウドサービスを利用しているのではないでしょうか。
AWSはよく利用されるクラウドサービスの1つであり、多くのサービスを気軽に利用できることから、弊社のようなスタートアップでも重宝させていただいております。
近年、セキュリティやガバナンスの強化のために、マルチアカウント構成でAWSを利用している組織も多いと思います。
マルチアカウント構成では、ワークロードに対して開発環境/ステージング環境/本番環境などの複数環境に分けることをお勧めします。
さらに、IAMユーザを特定のアカウントに集約させて、他のアカウントにスイッチロールさせると管理もしやすくなります。
変更管理と本番アクセス統制の課題
前述のマルチアカウント構成は便利ですが、少々困ることもあります。
- 変更管理
誰が、いつ、何を変更したかの記録は取れているでしょうか。
AWS CloudTrailやAWS Configを有効化しておくと変更を追うことは可能ですが、事後に追えるというだけであり、承認されていない変更が行われるのを防ぐことはできません。
また、エビデンスとしてコマンドログも取得しておきたいものです。
- 本番アクセス統制
本番環境にいつでもログインでき、許可なく変更できるようになっていないでしょうか。
承認されいない作業を知らない間に本番環境で実施されることは、思わぬ障害を招くことになります。
スイッチロールする権限を与えないというのも可能ですが、手作業はミスのもとですし、頻繁にリリースが行われるスタートアップでは自動かつ迅速に実施したいものです。
弊社では、この課題に対応するためにChange Managerの仕組みを活用しています。
設立時からこの仕組みを使って、多くのサービスを安全にリリースした実績があるので、どのように実装したのかを具体的に紹介していきたいと思います。
最終的な全体図は以下になります。複雑そうに見えますが、順を追って解説していきますのでご安心ください。
まとめ
今回の「①動機づけ編」では、変更管理と本番アクセス統制の必要性について紹介しました。
セキュリティやガバナンス強化のため、変更の記録を追うことができ、本番環境へのアクセスに承認を得るという業務フローは重要になります。
次回の「②マルチアカウント&IAM設計編」では、本番アクセス統制の前提となるマルチアカウント設計とIAM設計の勘所を紹介します。
