ソフトウェアのインストールをピアレビューの「許可」と「拒否」により決定し、スケーラブルな保護を可能に
Google Cloud Japan Team
※この投稿は米国時間 2021 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。
あらゆる IT 組織で確実に設置する必要があるコントロールの中でも、最も重要なのがマルウェアのブロックです。「デフォルト許可」ポリシーでは悪質と判明しているソフトウェアのみをブロックしますが、「デフォルト禁止」ポリシーを使用し、許可されているソフトウェア以外のすべてをブロックする方が安全です。言うまでもありませんが、事前に用意されている以外のソフトウェアを従業員がインストールすることを自由に許可するほど、このポリシーを管理することは困難になります。この自由度に加えて、Google のようなエンタープライズの規模を考えれば、中央のスタッフが一手に承認を管理することはほぼ不可能となります。
それでは、管理担当者のスケーリングが非実用的なことを踏まえて、この作業のスケーリングという課題にどのように取り組めばよいでしょうか。Google の回答は、Upvote という、ソフトウェアを許可するという作業の負荷を、「ソーシャル投票」と呼ばれるプロセスでユーザー全体に分散するシステムです。これは、ポリシー承認のピアレビューに相当するものと考えてください。
仕組み
Upvote は Google App Engine 上に構築され、ユーザーが投票するためのウェブベースのフロントエンドと、Mac OS では Santa システム、Windows では Carbon Black Protection（従来の Bit9）システムで動作するポリシー サーバーで構成されます。
ユーザー（この例では Mac ユーザー）が未知のバイナリの実行を試みると、Santa（「ロックダウン」モードで実行され、許可されたソフトウェアのみの実行を許可します）はそのバイナリをブロックし、Upvote はユーザーに対して、バイナリの実行を許可するかどうか投票を行えるようにします。ユーザーが正しい情報に基づいて決定を行えるよう、VirusTotal 分析が公開されます。他のユーザーも許可に投票し、票の合計数が一定のしきい値に達すれば、許可に投票したユーザーのみがソフトウェアを実行できます。
このしきい値は「ローカル」で、Upvote で適用されるしきい値にはもう一つ「グローバル」もあります。ローカルしきい値に達した後も投票は続けられ、ほかのユーザーがソフトウェアを実行するには同じく許可に投票しなければなりません。より大きなグローバルしきい値に達したときに投票は終了し、その時点で初めてすべてのユーザーがソフトウェアの実行を許可されます。これらのしきい値は設定可能です。
投票の実施中に、ユーザーがそのバイナリをマルウェアとしてフラグ付けする反対票を投じた場合、管理者がバイナリを審査してフラグ付けを解除するか、反対投票してマルウェアとして却下するまでの間、投票は一時的に停止されます。
Upvote は集中ポリシー サーバーとして、バイナリのメタデータやポリシーの更新を Santa と定期的に同期するため、ユーザーは特定のバイナリを実行できるかどうかを数分以内に知ることができます。
信頼できる既知のソースから得られたソフトウェアが不必要にブロックされることを回避するため、Upvote では管理者レベルで認定承認を行うことができ、署名チェーン内の承認済み証明書があるソフトウェアはユーザーが自動的に実行できます。Mac ユーザーの場合、Upvote でバンドル投票を行うこともできます。ユーザーがアプリの実行を試みてブロックされた場合、膨大な数のバイナリについて個別に投票することは非常に大変です。このため、Upvote ではユーザーがアプリのバイナリ全体に対してバンドルで投票できます。
ユーザーは信頼できるのか
ソーシャル投票によって許可リストに登録すると、それが実際に安全なのかという別の疑問が発生します。ユーザーが意図しなくても、マルウェアを許可してしまうことはないのでしょうか。
この方法にある程度のリスクが伴うことは疑いありません。Upvote では、ユーザーが VirusTotal 分析を利用して十分な情報に基づいた決定を下せるようにすることで、このリスクを最小化しています。しかし、さらに重要なのは、Upvote のしきい値適用です。感染の可能性があるのは、ユーザーが投票した一部のコンピュータにデフォルトで制限されます。フリート全体は、グローバルしきい値に達するまで保護されます。当然、このグローバルしきい値はきわめて高いレベルに設定するべきです。
別の大きな利点は、ユーザーの警戒心が自然に確立されることです。ドライブバイ インストールのような隠れた悪用は Upvote が自動的にブロックするため、ユーザーは意図しないソフトウェアの実行を確認しなければならなくなります。これにより、すべてのユーザーがテクノロジーとデータをより注意して見守るようになります。
これらの利点は、ユーザーが投票を行うリスクを上回るものであると考えています。また、大規模または成長中の組織におけるスケーリングの余地だけでなく、管理側によるブロックを回避し、必要なソフトウェアをよりコントロールできることでユーザーが得られる利便性、そしてさらに重要な生産性の向上も、あらゆる組織にとって大きな利益となります。
継続的な開発
Google は社内で Upvote の開発と改良を積極的に進め、段階的に進化させています。共有したオープンソース コードを基礎として、次の機能も実装することを決定しました。
プッシュ通知: これまで Santa クライアントは次の同期まで Upvote からポリシーの更新を受信できず、最大 10 分間を要していましたが、待たずに更新を受け取れるようになりました。ユーザーは、投票してから数秒以内に通知を受け、バイナリを実行できます。また、マルウェアの禁止も数分以内にフリート全体に伝搬されます。
ロックダウン免除: 新しいバイナリをビルドして実行するユーザーにとってはロックダウンが不便なため、デフォルトのロックダウン モードの無効化をリクエストできます。ユーザーがポリシー チェックに合格すれば、そのユーザーのマシンは「モニタリング」モードに切り替わり、拒否されているソフトウェアのみがブロックされるようになります。このリクエストに対する許可は、組織のリスク許容度によっては例外的なケースに限定する必要があります。
過渡的な許可 / 拒否: デベロッパーが頻繁にコードをコンパイルする場合、コンパイルごとにロックダウンの対象となるため、ロックダウン システムが大きな負荷となります。管理者はこの機能を使用して、コンパイラを「聖別」し、そのコンパイラでコンパイルされたすべてのバイナリは、コンパイルに使用されたマシンで実行可能にできます。
詳細はコードをご参照ください
Google はこのソリューションを引き続き Google 社内で発展させていきますが、以前の実装をどのように処理したかを示すため、サンプルリポをリリースしました。このコードベースが今後更新される予定はありませんが、許可 / 拒否の大規模な決定をより的確に処理したい他社のお役に立ればと願っております。
Upvote の詳細やデモについては、MacDevOpsYVR にあるこのプレゼンテーションをご参照ください。
この投稿は、Upvote エンジニアリング チームの Ben Grooters と Matt Doyle の見識と技術により可能となりました。このトピックに関する多くの質問に回答していただいたことに感謝申し上げます。
-Google 社員エンゲージメント担当 Michael Suh
-Google Cloud デベロッパー アドボケイト Max Saltonstall
