金融企業が親切にラベル付けされたスプレッドシートにDB認証情報を保存

PWNED 再び、PWNED週刊コラムへようこそ。ここでは、流砂の山を見つけた後、そのままそこに飛び込んでしまったIT探偵たちの冒険を語ります。今週の話では、機密情報を非常に脆弱な場所に保管し、その後十分に保護しなかったことが関係しています。

この話は、ソフトウェア開発企業であるInnowiseの戦略的実践の責任者であるStanislav Kazanovから我々の元に届きました。数年前、Kazanovと彼のチームは、経営陣が「軍事グレード」のセキュリティシステムの開発に100万ドル以上を投資したフィンテックスタートアップのコンプライアンスおよびデータアーキテクチャ監査を実施するために雇用されました。このシステムには、生体認証MFA、エンドポイント検出、および大量の物理的セキュリティが完備されていました。

監査中、Kazanovは会社のSharePointサイトにログインし、どの従業員でもアクセスできる社内イントラネット上の「DevOps_Handoff」というフォルダを見つけました。そのフォルダ内には、非常に曖昧で欺瞞的なファイル名Prod_DB_Root_Creds_DO_NOT_SHARE.xlsxのスプレッドシートがありました。明らかに、このネーミング規則は潜在的なハッカーを撃退するでしょう。

良い面では、Excelファイルはパスワードで保護されていました。だから、少なくともそれはありますが、本当にそれほどの保護があったのでしょうか?

Kazanovがリードエンジニアにパスワードを尋ねると、彼はとても恥ずかしがって足を見つめ、答えをぼそぼそと言いました:「それは[会社名] + [年]です。」 我々は会社の実際の名前を知りませんが、それがContosoだったとしましょう。したがって、パスワードはcontoso2026になります。それは正確には「admin123」ではありませんが、推測するのに十分近いです。

リードエンジニアはKazanovにファイルが存在する理由を説明しました。どうやら、社内DevOpsチームと外部のDBAチームは、どのエンタープライズグレードのパスワードマネージャーを使用するかについて意見が対立していました。この意見対立を「一時的に」解決するために、彼らはルートDB認証情報とマスターAWS IAMキーをこのスプレッドシートに投棄しました。このスプレッドシートは、私たちのヒーローがそれを見つけた時点で、驚くべき8か月間存在していました。

私たちの話はここで終わります。Kazanovの介入後、そして悲劇が起こる前に、この問題が解決されたと仮定しています。しかし、リソースをセキュリティで保護する方法についての意見の相違は、危険な妥協につながることができることを示しています。

この場合、社内DevOpsチームは、契約業者と彼ら自身が使用するパスワードマネージャーについて最終的な決定権を持つべきでした。スプレッドシートが強力なパスワード保護を有していたとしても、この対立により秘密をスプレッドシートに入れることが許可されるべきではありませんでした。

サイバーセキュリティの最も基本的な原則は、個別のアクセスと認証情報を、それを本当に必要としている者だけに付与することです。しかし、ここでは、ファイルはすべての従業員やKazanovのような契約業者でもアクセス可能なイントラネット上にありました。これはフィンテック企業であったため、関与するデータは数百万ドルまたは数十億ドルの人々のお金に関連している可能性がありました。これは深刻な状況であり、セキュリティについてこんなに不注意な人は、資産やトランザクションで1セント弱も処理する価値がありません。

ネットワークに大きな穴を開けたままにしている人についての話はありますか? [email protected]で共有してください。匿名性は要求に応じて利用可能です。 ®

翻訳元: https://go.theregister.com/feed/www.theregister.com/2026/04/30/finance_company_stored_their_db_pwned_column/

ソース: go.theregister.com