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

[高橋睦美，ITmedia]

備えはしていたはずなのに　それでも事故が起こった理由

　ただ、ラックも今回起きたようなトラブルを想定していなかったわけではない。同社はセキュリティサービスを手掛けてきた経験を基に、コスト超過やセキュリティインシデントについて、有事を想定した対策をしてきたという。

　例えばコスト超過に対しては、アクセス管理サービス「AWS Service Control Policies」を活用。機械学習などであまりに多くのデータを処理して課金額が跳ね上がりそうな場合は、相談の上で可否を判断し、セキュリティとコストの観点を加味しながら対応していた。

　セキュリティも同様だ。検証環境でもAWSのセキュリティ機能「Amazon GuardDuty」「Security Hub」などを活用。設定ミスなど、本来あるべき設定からの逸脱があれば把握できる仕組みを整えていたという。

　「例えば、未熟なエンジニアがAWSを使う際に、インターネットに向けてポートを無制限に開放してしまうようなネットワーク設定を入れてしまった場合にはAmazon GuardDutyやAWS Security Hubで検知し『今、無制限のアクセスが設定されています』といった通知が入るようになっている。これを受けて、設定を改善するようアナウンスすることで、自由にさせつつ締めるべきところは締めてきた」（土井さん）

　セキュリティチームでは週に1回、定例会を実施。Amazon GuardDutyやAWS Security Hubのログをメンバー内で確認して、どれは問題ないか、どれはリスクがありそうかといった事柄を話し合っていた。大量のアラートの中から深刻なものとそうでないものを切り分けられる体制も整えていたという。

土井秀記さん

　ただ、あまりに規則をガチガチに固めてしまうとエンジニアの自由度が失われ、新機能をスピーディーに検証したくてもできない事態になりかねない。「セキュリティは絞りつつ、でも、エンジニアの『やりたい』には応えていきたいというのが管理者チームの希望」（土井さん）。

　そこで、検証環境に限っては本番システムやその検証システムで行うゲートレビュー（次工程への移行に際するチェック工程）を省き、スピード感を担保する方針で運営していた。ただ、今回の事故はこの方針が裏目に出てしまった。

不幸中の幸いで切り分けは迅速に、事前のセキュリティ対策が奏功

　事故の発生後、管理チームが最初に疑ったのは課金を通知するツールの不具合、そして、セキュリティインシデントの発生だった。

　「まずセキュリティインシデントを疑った。機密情報や顧客情報は一切保存していなかったが、何者かに侵入され、外部のWebサイトにDDoS攻撃が行われてしまった可能性や、マイニングなど他の処理が動いてしまったのではないかという可能性を考えた」（土井さん）

　しかし前述の通り、検証環境チームではセキュリティに関してはあらかじめ対策を施していたことから、セキュリティに問題があった可能性は低かった。週に1回の定例ミーティングの場で定点観測を行っていたこともあり、確認すべきデータもそろっていたという。

　「前週と比較しても、セキュリティ的に何も大きなイベントが起きているようには見えなかった。5月4日を中心にログイン履歴を確認しても不正なログインをされた痕跡はなかったことが確認できたので、早いタイミングで、セキュリティインシデントの可能性は非常に少ないと判断し、切り分けることができた」（土井さん）

　次に確認したのは、AWSのサービス別の利用料だ。ここでAmazon S3とAmazon CloudWacth、AWS CloudTrailの課金が多く、さらに前月に比べAWS Lambdaの稼働状況が非常に多いことが判明。調査を進め、問題のロジックにたどり着き、対処につながったという。

　「エンジニアが自由に技術検証ができる基盤を運営していくのがわれわれの役割であり、各ロジックの中身までは立ち入っていなかった。ただ、これが原因だろうというのは早いタイミングで把握できた」（土井さん）