セキュリティ
一時的なステージングサーバーであっても、しっかりとロックダウンしておく必要があります。
PWNED 週刊コラム「PWNED」へようこそ。ここでは、不注意によってサイバー犯罪者にデータへアクセスされてしまった事例から、重要な教訓を学びます。他人の失敗が、何をすべきでないかの参考になれば幸いです。
今回の失敗談は、AIレセプショニストや営業自動化といったビジネスAIサービスを提供する企業SmartReplで、マネージングディレクター兼AIソフトウェア研究者を務めるRichard Schut氏から寄せられたものです。以前の職場で、Schut氏は中堅規模の企業に勤めていた際、一部のローカルシステムをクラウドへ移行する前に潜在的な問題点を洗い出すためのセキュリティ監査に携わっていました。
Schut氏とそのチームは、社外ネットワークからアクセス可能なテスト環境が存在し、しかもそれが実際の顧客情報を含むデータベースに接続されていることを発見しました。これは、悪意ある人物が企業の貴重な情報を盗み出すために利用できてしまう、大きな穴でした。
「今回の状況で特に懸念すべき点は、この環境がもともと開発チームにとって短期的な目的のために作られたものだったことです」と同氏はThe Registerに語りました。「アプリケーションのデモと移行のテストを行う場所が必要だったため、ステージングインスタンスが急いで立ち上げられました。それが会社の恒久的なインフラの一部になることは、まったく想定されていませんでした」
残念ながら、このテスト環境は当初の構築から数カ月経った後もまだ稼働し続けていました。そして、構築した担当者たちは権限のない人物がアクセスすることを想定していなかったため、本番環境で使うような認証・アクセス制御の仕組みを導入していませんでした。
あなたの体験談をお聞かせください
誰かがネットワークに大きな穴を残してしまったエピソードをお持ちですか？
[email protected]までぜひお寄せください。ご希望があれば匿名での掲載も可能です。
このデータベースを含むSQLファイルには、何を含んでいるか疑いの余地がないほど、ずばり「master_test_final.sql」という名前が付けられていました。
「これは、セキュリティ上の問題が必ずしも高度な攻撃や特殊な脆弱性から生じるわけではないことを示す典型的な例でした」とSchut氏は述べています。「時に最大のリスクとなるのは、ほんの数時間だけ存在するはずだったものが、6カ月経ってもそのまま残っていたという、ただそれだけのことなのです」
Schut氏と同僚たちはこの脆弱性を発見した後、直ちにステージング環境へのアクセスを制限しました。その後、同氏とチームは、社内の他の開発環境やテスト環境を見直し、同様に悪用可能な状態のものがないかを確認する作業に着手しました。
ここから得られる教訓は、あのSQLファイルの中身と同じくらい分かりやすいものです。テスト用に作られた環境だからといって、セキュリティに手を抜いてはいけません。テストサーバーがたとえ1日しか稼働していなかったとしても、その1日は悪用され得る1日なのです。
「この一件で、ステージング環境に対する私の見方は完全に変わりました。ある環境が実データにアクセスできる状態にあるなら、それが1日、1週間、あるいは6カ月存在する予定だったかどうかに関わらず、実際のセキュリティ資産として扱わなければなりません」とSchut氏は語りました。®
