AWSの開発環境を触っているつもりが本番環境だった件

先日会社でAWSの開発環境を触っていたつもりが、本番環境を触っていたという事象が発生し、実際に、本番環境のサーバを再起動しサービス停止につながるという事件が起きました。今回はこちらの経緯と解決策を記載していきます。

事件発生の流れ

当時は、AWSアカウント構成はまず各アカウントを管理するアカウントを用意し、そこから開発、検証、本番にスイッチロールでログイン切り替えする構成になっておりました。

当時、開発者は開発環境のEC2サーバを再起動する動作確認をタスクとして依頼されていました。いつも通り、開発環境にログインし作業しているつもりですが、実際は本番環境へとログインをしてしまっていました。

開発者はもちろん本番環境へログインしたことも気づいてなく、開発環境だと思い込んで作業していました。その後、サーバを再起動しコンポーネントの命名が開発でないことに気づきここで初めて本番環境を触っていたことに気づきました。

本番環境へ常にPowerRoleでログインできる状態だったことが問題だと考えられます。本番環境へのログインは作業時以外はReadOnlyでのみログインする対策が必要です。

普段の検証、本番環境へのログイン権限は、ReadOnlyのみ用意します。作業時以外も本番環境へログインが必要なケースが存在するためReadOnly権限は付与しています。例えば、本番環境のログ確認やサーバ状況の確認など。

検証、本番環境で作業が必要な場合は、作業内容と作業時間を事前にAWSアカウント管理者へ申請する仕組みを導入しました。申請を承認したAWSアカウント管理者は、作業者のIAMUserへ本番環境のPowerRoleを付与します。

作業完了後は再度AWSアカウント管理者へ完了連絡を実施し、AWSアカウント管理者が作業者のIAMUserに付与したPowerRole権限を削除し、完了です。

最小権限の法則の大切さが身に沁みました。どの環境にも言えますが、本番環境は特に必要なときにのみ必要な権限を付与する必要があると感じてます。

また、本番環境へはスイッチロールではなく、完全にアカウントを切り分けるなどの仕組みも考えましたが、予算管理の変更や運用変更のインパクトが大きいということで不採用となりました。

これからAWS扱っていこうとしている方や、同じアカウント構成の方に注意喚起として知っていただければ幸いです。