クラウドセキュリティの
学び場

今回の解説ニュース

クラウド製品の定期メンテナンスにおいて、意図せず顧客データが削除されてしまったということです。人為的なオペレーションミスにより発生したインシデントの内容と対策について説明します。

今回のインシデントは、顧客が使用するクラウド製品のデータが意図せず削除され、アクセスできなくなりました。原因として、削除を依頼したチームと、削除を実行したチーム間の「コミュニケーションギャップ」と、リクエストされている削除の種類の確認を促す警告が表示されないという「不十分なシステム警告」が挙げられています。なお、本事象はサイバー攻撃の結果ではなく、顧客データへの不正アクセスもないということです。

再発防止策として、全てのシステムでの共通した「論理削除」の確立、ディザスタリカバリプログラムを加速し複数サイト・複数製品の削除イベントの復元を自動化、大規模なインシデントのためのインシデント管理プロセスの見直し、大規模なインシデントコミュニケーションプレイブックの作成を行うということです。

原因はサイバー攻撃ではなかった、挙げられた2つの問題

インシデントの原因として挙げられている2つの問題である、コミュニケーションギャップと不十分なシステム警告について説明します。

問題１）コミュニケーションギャップ

コミュニケーションギャップについて、削除を依頼したチームと、削除を実行したチームの間にコミュニケーションのギャップがあり、削除の対象となっているアプリのIDを提供する代わりに、アプリを削除するクラウドサイト全体のIDを提供してしまったことが挙げられています。本来、必要とされるIDとは異なるIDで、かつ広範囲を網羅するIDが提供されたことにより、想定以上のデータが削除されてしまったことが考えられます。

問題２）不十分なシステム警告

不十分なシステム警告について、削除を実行するために使用されたAPIは、サイトIDとアプリIDの両方の識別子を受け入れ、入力された値が正しいことを前提としていた事が挙げられています。つまり、リクエストされている削除の種類がサイトなのかアプリなのか、確認を促すような警告がなされないスクリプトであったため、いかなるIDが渡されても削除されたことが考えられます。

まとめると、人為的なミスを止める機能が実装されていないスクリプトで人為的なミスが発生したことによるインシデントであったということができます。

人為的なミスからのインシデント、再発防止策は？

今回のインシデントへの再発防止策として挙げられている、論理削除、ディザスタリカバリ、インシデント管理プロセスの見直し、インシデントコミュニケーションプレイブックについて説明します。

論理削除

論理削除とは、データを削除する際に、データが無効であることの情報を付加することで、削除したことと同じ扱いにする方式です。実際のデータを削除する物理削除とは異なり、論理削除が意図しない削除であった場合、一定条件がそろえば簡単に復元することができます。今後は、必ず論理削除を経てから顧客データを削除するということです。

ディザスタリカバリ

ディザスタリカバリとは、災害復旧と訳される、組織が事業を継続させるために選択できる考え方のひとつです。大規模障害が発生した際に、復旧できるまでの時間や、どこまでデータを失わずに復旧できるかなど、目標を設定して体制を構築します。今後は、定期的な演習を実施し、目標復旧時間の達成を目指すということです。

インシデント管理プロセスの見直し

今回の規模を想定したシミュレーションを実践して、多くのチームが並行して対応できるよう、トレーニングとツールを改めるということです。

インシデントコミュニケーションプレイブック

インシデントを早期に認識し、インシデントに関する広報を数時間以内に公開する体制を整えるということです。

今回は、甚大な被害を及ぼしたクラウド製品の大規模障害についてお届けしました。再発防止策は一般企業の障害対応にも参考になりますので、関連する業務に携わる方はぜひ一度目を通してみてください。