本当にあったIT怖い話　AWSの設定ミスで300万円のコスト超過、1日1回だったはずの処理が1分で160万回に　当事者に聞く反省点（3/3 ページ）

公開 2022年09月09日 13時01分

更新 2022年09月09日 01時01分

著者

高橋睦美

[ITmedia]

印刷する

ミスは起こることを前提に、素早く気付き、対応する仕組み作りを

　今回の大量課金事件を踏まえてラックではさまざまな角度から振り返りを行い、どうすべきかを議論したという。結果として、ロジックの実装だけでなく、システム運用にも不備があったと捉えている。

　「まず、休日にかかわる時期のチェック体制がなかったことが反省点として挙げられる。休日でも異常に気付き、のろしを挙げる対応が必要だろうと考えている。またロジックについては、意図しない無限ループを起こさないよう、有識者による技術的なレビューを行うべきだった」（土井さん）

　「コストのチェックは1日に1回行っていたが、その1日で一気に数十万から100万円を超える課金が行われてしまうと手の打ちようがない。そこでAWS CloudTrailを用いてAPIの実行回数を把握・可視化し、想定外の何かがぐるぐる回っているような事態が起きた場合には通知する仕組みを入れた」（土井さん）

　そもそも、原因が社員向けの技術検証環境であり、重要なデータが何もなかったことから「何かが起きる」ことを想定していなかったのが根本的な問題だった可能性もある。「今回の事故を防げるポイントはいくつかあったと思う。ただ、やはりそういったミスは起きるものだと想定した上で準備していかなければいけない」（土井さん）

　一方で、Amazon GuardDutyでの監査や、AWS Security Hubによってアクセス元のIPアドレスを制限するといった従来の施策が無意味だったわけではない。原因を早期に切り分ける上で役立ったと片桐さんは振り返る。

片桐貴之さん

　今後はさらに、「CSPM」（Cloud Security Posture Management、クラウドサービスの設定を管理し、ミスがあったときに通知するツール）と呼ばれるソリューションの活用も検討している。設定の妥当性を検証したり、アカウント管理や新規サービス利用時の手順・プロセスを標準化したりし、運用が適切かどうか見ていくような仕組みも重要と考えているという。

　「これで十分かといわれると難しいが、やれるところはやってきた。今後も同じようにやっていく」（土井さん）

　トラブルに見舞われたラックだが、クラウド利用を萎縮させたり、利用環境に制限を加えたりといった対応はしない方針という。セキュリティインシデントと同様に、事故を起こした人を責めるのではなく、報告したことに感謝し、問題を改善して再発防止に取り組む動きを追求していくとしている。

　「未熟なメンバーであってもそれを守れる仕組みを整え、エンジニアのやりたいことがやれるよう、ひいてはクライアントのためになるエンジニアを育てていきたい」（土井さん）