今回の大量課金事件を踏まえてラックではさまざまな角度から振り返りを行い、どうすべきかを議論したという。結果として、ロジックの実装だけでなく、システム運用にも不備があったと捉えている。
「まず、休日にかかわる時期のチェック体制がなかったことが反省点として挙げられる。休日でも異常に気付き、のろしを挙げる対応が必要だろうと考えている。またロジックについては、意図しない無限ループを起こさないよう、有識者による技術的なレビューを行うべきだった」(土井さん)
「コストのチェックは1日に1回行っていたが、その1日で一気に数十万から100万円を超える課金が行われてしまうと手の打ちようがない。そこでAWS CloudTrailを用いてAPIの実行回数を把握・可視化し、想定外の何かがぐるぐる回っているような事態が起きた場合には通知する仕組みを入れた」(土井さん)
そもそも、原因が社員向けの技術検証環境であり、重要なデータが何もなかったことから「何かが起きる」ことを想定していなかったのが根本的な問題だった可能性もある。「今回の事故を防げるポイントはいくつかあったと思う。ただ、やはりそういったミスは起きるものだと想定した上で準備していかなければいけない」(土井さん)
一方で、Amazon GuardDutyでの監査や、AWS Security Hubによってアクセス元のIPアドレスを制限するといった従来の施策が無意味だったわけではない。原因を早期に切り分ける上で役立ったと片桐さんは振り返る。
今後はさらに、「CSPM」(Cloud Security Posture Management、クラウドサービスの設定を管理し、ミスがあったときに通知するツール)と呼ばれるソリューションの活用も検討している。設定の妥当性を検証したり、アカウント管理や新規サービス利用時の手順・プロセスを標準化したりし、運用が適切かどうか見ていくような仕組みも重要と考えているという。
「これで十分かといわれると難しいが、やれるところはやってきた。今後も同じようにやっていく」(土井さん)
トラブルに見舞われたラックだが、クラウド利用を萎縮させたり、利用環境に制限を加えたりといった対応はしない方針という。セキュリティインシデントと同様に、事故を起こした人を責めるのではなく、報告したことに感謝し、問題を改善して再発防止に取り組む動きを追求していくとしている。
「未熟なメンバーであってもそれを守れる仕組みを整え、エンジニアのやりたいことがやれるよう、ひいてはクライアントのためになるエンジニアを育てていきたい」(土井さん)
Copyright © ITmedia, Inc. All Rights Reserved.
Special
PR