あなたのITチームは、つい先日、徹底したセキュリティテストを完了したところです。ネットワークは厳重にロックダウンされ、組織のテックスタック全体でMFA（多要素認証）が強制されています。従業員はフィッシング対策トレーニングも受講し終えました。
ところが昨日、経理部のボブが「リンクを知っている全員が編集可」に設定されたGoogleスプレッドシートのリンクで、第3四半期の売上予測を共有しました。ボブは、彼なりに仕事をこなしていただけです。しかし、それでもボブのGoogleスプレッドシートのリンクが、システム全体の弱点になる可能性は消えません。
インサイダー脅威というと、たいていは不満を抱えた従業員がデータを盗むケースを指します。しかし、ボブのような善意の人たちが、承認済みツールではやりたいことをすべて実現できないためにスプレッドシートに手を伸ばすケースのほうが、はるかに一般的です。
高機能なERPソフトが、従業員のやりたいことの90％はこなしてくれるかもしれません。ですが残りの10％、たとえばグラフの微調整やPDFレポートの書き出しなどは、どうしてもプロジェクトを完遂させるには物足りないことがあります。
そこで人々はデータをエクスポートします。スプレッドシートにデータを取り込み、最後の10％の作業を行い、それから — もしかしたら — 公式システムを更新したり、突き合わせたりするかもしれません。そのスプレッドシートは、その後もリンクを持つ誰かの手元で、どこかに浮遊し続けます。これを「シャドウスプレッドシート」と呼ぶことにしましょう。
Grist Labsでは、ITチームがシャドウスプレッドシートに日常的に対処している現場を見てきました。私たちは、こうしたシャドウを葬り去るためのオープンソースのスプレッドシート兼データベースを開発しましたが、その話は後ほどにしましょう。まずは、なぜシャドウスプレッドシートが本当の問題なのかを見ていきます。
シャドウスプレッドシートがセキュリティリスクになるまで
チームが重要なデータをスプレッドシートに移すとき、たいてい次の2つのシナリオのどちらかが発生しますが、どちらも理想的とは言えません。
デフォルトでの過剰共有
誰かがコラボレーション用のマスタースプレッドシートを作成します。共有設定を「このリンクを知っている組織内の全員」にして、Slackチャンネルの全員に一斉送信します。
これで会社全体の誰もが、給与データ、顧客の支払条件、戦略的な拡大計画、あるいはそのスプレッドシートに今後含まれるあらゆる情報にアクセスできる状態になります。実際に見る人は少ないかもしれませんが、「アクセスできる人」が誰なのかをコントロールする力は、すでに失われています。通知を受け取ることすらできない可能性も高いのです。
セキュリティ面はさておき、このスプレッドシートがSheetsやExcelの限界に近づき始めるかもしれません。従業員はスプレッドシート上にアプリを構築することがよくありますが、それをアプリと呼ばないだけです。こうしたスプレッドシート製アプリの壊れやすい数式は、ちょっとしたタイプミスを3時間のトラブルシューティング作業に変えてしまうことがあります。
そして、同じことが二度と起きないようにと、ITは重要な各セクションの上に真っ赤な行を追加し、「警告：この数式には絶対に触らないでください」と書き込みます。経理部のボブは、その数式に即座に触ります。
スプレッドシートのスプロール（拡散）
過剰共有を避けようとして、人々は神経質になり、「安全な」コピーを作り始めます。経理部用のバージョン、経営陣用のバージョン、雇ったコンサルタント用のバージョン…。同じスプレッドシートが6種類も存在し、メールやSlackのDM、SharePointフォルダを通じて出回ります。誰かが個人のGoogleドライブにもコピーを持っているようです。
どれが正なのか、あるいは最新なのか？誰が何にアクセスできるのか？誰かがエラーを見つけたとき、どのバージョンを修正すべきなのか？ そして何よりも重要なのは、これがどの程度の情報漏えいリスクを生んでいるのか、という点です。
可視性を優先した結果、従業員はデータの完全性を犠牲にしてしまい、監査証跡は跡形もなく消えてしまいます。
CISOたちが夜も眠れなくなる理由
ボブは、顧客分析のスプレッドシートを、プロジェクトを担当しているコンサルタントに転送します。そのスプレッドシートには複数のタブがありますが、コンサルタントが必要なのは3番目のタブだけです。ボブが存在を忘れていた7番目のタブには、主要顧客の契約条件、更新日、価格情報が含まれています。
コンサルタントは、個人情報窃盗を企んでいるわけではありません。しかし、彼らはあなたの組織のDLPポリシーに縛られているわけでもありません。その機密情報は、すでにあなたの防御線の外側にあり、今後どこへ流出するのか、まったく見当がつきません。
シャドウスプレッドシートは、マッピング不可能な攻撃面を生み出します。いくつのコピーが存在し、どこに保存され、誰がアクセスしてダウンロードしたのかが分からなければ、分かっているのは「まずい状況にある」という事実だけです。
実際に悪意ある人物が関与している場合、断片化されたデータはもっともらしい言い逃れの余地を与えます。監査ログ付きの権威あるデータソースがなければ、その人物がシート内で何にアクセスし、何を変更し、何をエクスポートしたのかを証明する術はありません。
公式システムが実務を支えるには堅すぎるなら、人々は必ずそれを迂回します。では、どう対処すればよいのでしょうか？
なぜ「もっともらしい解決策」が失敗するのか
トレーニングでは、人々のニーズを満たさないツールを修正できません。また、セキュリティコントロールと「とにかく仕事を終わらせたい」という現場の欲求との衝突を、ポリシーだけで乗り越えることもできません。
では、締め付けを強化したらどうでしょうか。ファイル共有をロックダウンし、機密データを含むスプレッドシートの添付ファイルを検知・ブロックするDLPを導入する？ 多くの場合、人々はさらにセキュリティの低い回避策 — USBドライブや個人のDropboxアカウントなど — を見つけてしまいます。なぜなら、彼らにはこなすべき仕事があるからです。これでは、問題の追跡はさらに困難になります。
では、チームの働き方に特化した社内アプリを構築したらどうでしょうか？今度は、開発に6か月、コストは20万ドル以上という話になります。
要件定義を行い、外部委託先を雇い、調達プロセスを乗り越える頃には、9か月前にソリューションを必要としていたチームは、すでにさらに十数個のシャドウスプレッドシートを出回らせていることでしょう。そしてビジネスニーズは必ず変化するため、常に後追いのゲームが続きます。カスタム開発は、柔軟性とセキュリティの問題を解決する代わりに、終わりのない保守負担を生み出します。
私たちが見出したのは、人々がスプレッドシートを使うのは、スプレッドシートがほとんどのことに対して非常に優れているからだ、ということです。スプレッドシートは、多くの人が理解している普遍的なインターフェースです。多くのSaaSプラットフォームは、本質的には「見た目の良いUIをかぶせたスプレッドシート」に過ぎません。スプレッドシートと戦うということは、多くの場合、組織の大半と戦うことを意味します。
では、スプレッドシートと戦えないのなら、それを「保護」してはどうでしょうか？
Grist：スプレッドシートが影から抜け出す場所
Grist Labsでは、スプレッドシートの長所を活かしつつ、短所を避けるソフトウェアを作ることを目指してきました。私たちは、古典的な表形式グリッドの長所と短所を熟知した元Google Sheetsエンジニアによって設立されました。Gristは見た目も操作感もスプレッドシートですが、その基盤にはリレーショナルデータベースがあり、きめ細かなロールベースのアクセス制御を可能にしています。
Gristは自社インフラ上にセルフホストできるため、機密データが自分たちの環境の外へ出ることはありません。RBAC（ロールベースアクセス制御）は列レベル・行レベルで設定できるため、ユーザーはリアルタイムで共同作業を行いながら、外部の委託業者から経営陣に至るまで、誰もがコピーを作ることなく「見るべきものだけ」を見ることができます。これは本物の「単一の真実のソース」です。
さらに、ボブが重要な数式を二度と壊せないように制限することもできます。
GristはSSOと連携でき、VPNの背後やエアギャップ環境で動かすことも可能です。エンタープライズ版には、追加の管理者向けコントロールが含まれています。たとえば、インストール環境全体でリンク共有されているドキュメントの一覧を確認したり、ボブが正確に何にアクセスできるのかを把握したりできます。また、外部のSIEMシステムに接続できる監査ログを有効化することも可能です。
ユーザーにとって直感的で馴染みのあるツールがあれば、導入は現実的になります。スプレッドシートの経験に逆らうのではなく、それを、潜在的な悪意ある行為者を除く「全員にとって機能する共通の基盤インターフェース」として活用しましょう。
