ほとんどの企業は社内システムだけに依存しているわけではありません。クラウドプラットフォーム、給与計算サービス、マーケティングツール、ITパートナー、そして日々の業務を支える数十ものSaaSアカウントを利用しています。各ベンダーは問題を解決し、同時に新たな信頼関係を築きます。
ベンダーリスク管理（VRM）とは、サードパーティとの取引から生じるセキュリティリスクを評価、承認、監視、見直しするプロセスです。これにより、どのベンダーが機密システムやデータにアクセスできるか、そのベンダーがどのような管理策を講じているか、そのアクセスを正当化できるほどセキュリティ対策が十分か、契約終了やインシデント発生時にどれだけ迅速にアクセスを変更できるかを企業が理解できるようになります。
自社でベンダーリスク管理にどう取り組むか、既に取引のあるベンダーをどう評価するか、サードパーティベンダーのリスクをどう分類するか、ベンダーセキュリティチェックリストに何を含めるか、そして長期的なリスクとなる前にベンダーの認証情報をどう管理するかを説明します。
Proton Pass for Businessがベンダーアクセス管理をどのようにサポートするか
ベンダーリスク管理の対象範囲
ベンダーリスク管理は単純な原則に基づいています。データ、システム、ビジネスプロセスに触れるすべての外部関係者が、リスクプロファイルを変化させるのです。
ほとんどのベンダーリスクは日常業務によって生じます。たとえば、チームがスピード、専門知識、または社内にないソフトウェアを必要とするため、サードパーティの代理店がビジネスネットワークに招き入れられることがあります。アクセスが許可され、データが共有され、その関係が日常業務の一部として構築されます。
リスクは、そのベンダーが何にアクセスできるのか、そのアクセスと侵害の間にどのような管理策が存在するのか（多要素認証（MFA）、名前付きアカウント、暗号化など）、またはそのアクセスをどれだけ迅速に発見し遮断できるのかが明確でない場合に生じます。アクセスの失効は通常、システム自体またはSCIMプロビジョニングを通じて行われますが、ほとんどの企業にとって難しいのは、実際にどこを探すべきかを知ることです。
ベンダーは、大規模なクラウドプロバイダー、ニッチなSaaSプラットフォーム、フリーランスの開発者、会計事務所などかもしれません。ベンダーの規模や業界は主な問題ではありません。そのアクセスが問題なのです。
ベンダーリスクはいくつかの異なる形で現れます。
- データリスク： ベンダーが業務データや個人データを閲覧、保存、処理、転送、または削除できる。
- アクセスリスク： ベンダーがシステムにログインし、設定を管理し、統合機能を使用し、または管理パネルに到達できる。
- 運用リスク： 企業が重要なワークフロー、サービス、または顧客向けプロセスをベンダーに依存している。
- コンプライアンスリスク： ベンダーの役割が、データ保護法（GDPR遵守要件など）、契約上、または業界固有の要件に基づく義務に影響を与える。
- 認証情報リスク： ベンダーのアクセスが共有、再利用、文書化されていない、または失効が困難である。
ベンダーリスクは、その場では理にかなっている小さなアクセスの選択によってしばしば蓄積されるため、発見が困難です。チームメンバーが共有すべきでないログイン情報を共有したり、サプライヤーのアカウントが便宜のために権限を保持し続けたり、プロジェクト終了後に誰も見直さない請負業者の権限などです。時間の経過とともに、誰も積極的に管理していなくても、これらの例外はビジネス環境の一部となっていきます。
ベンダーリスク管理（VRM）プロセスの構築方法
効果的に行えば、ベンダーリスク管理はすべての意思決定を複雑にするわけではありません。より明確な制限を設けてアクセスを許可するための信頼できるフレームワークを作ります。自社のベンダーリスクを評価し、リスク管理戦略を構築するために企業が取れる重要なステップを探ります。
1. ベンダーの一覧を作成する
セキュリティ証拠を求められたり、契約を更新したりするときに、ベンダーリスク管理を受動的なタスクにするのではなく、能動的なタスクにしましょう。まず、既に業務内に存在するベンダーを把握することから始めます。
ベンダー一覧の作成は複雑である必要はありません。以下の点を明確に示す必要があります。
- 誰がその関係を所有しているか
- ベンダーが提供するサービスは何か
- どのシステムやデータにアクセスできるか
- 個人データが関与しているかどうか
- サブプロセッサーが使用されているかどうか
- 次回の契約更新またはセキュリティレビューの時期
アクセスは記録すべき重要な要素です。なぜなら、ベンダーによって特権やアクセスニーズが異なるからです。名前付きアカウントを使用するベンダーもあれば、共有認証情報、管理者アクセス、APIキー、共有受信トレイ、または当初の必要性がなくなった後も長期間有効なままの一時的なログイン情報に依存するベンダーもあります。これらの違いは、オフボーディングやインシデント発生時にアクセスをどれだけ迅速に変更できるかを左右するため、重要です。
一覧には、正式な調達プロセスの外にある小規模なベンダーも含めるべきです。プラグイン、コンサルタント、フリーランスの開発者、代理店、専門的なSaaSサービスは、機密データや重要なワークフローに触れる場合、重大なリスクを生む可能性があります。
一覧の主な価値は、より優れたアクセス制御を生み出すことにあります。ベンダーとの関係が終了したとき、どのアカウントを無効化し、どの認証情報をローテーションし、どの統合を削除し、保管データをどうするべきかを企業が把握できます。
2. 利便性ではなくリスクでベンダーを分類する
ベンダーをマッピングした後、生じるリスクに応じてグループ化します。これにより、プロセスを適切な規模に保ち、すべてのサプライヤーを無害か重要かのどちらかとして扱うことを避けられます。
高リスクベンダーは通常、機密データを処理し、重要な業務をサポートし、または特権アクセスを保持しています。これには、クラウドインフラストラクチャ、ユーザー情報プラットフォーム、給与計算、財務、人事システム、マネージドIT、セキュリティサービス、またはコアSaaSプラットフォームが含まれる場合があります。
中リスクベンダーは重要な業務をサポートしますが、アクセス範囲はより狭くなっています。これには、コラボレーションプラットフォーム、分析ツール、プロジェクト管理システム、ヘルプデスクソフトウェア、または限られた権限を持つ代理店が含まれる場合があります。
低リスクベンダーは、機密データや業務上重要なシステムへのアクセスがほとんどまたはまったくありません。記録は必要ですが、役割が変わらない限り、同じ深さのレビューは必要ありません。
階層は、ベンダーの評判、規模、価格ではなく、実際のアクセスに基づくべきです。よく知られたプラットフォームでも、機密データを保管している場合は高リスクになる可能性があります。小規模な請負業者でも、管理者権限を保持している場合は高リスクになり得ます。
リスク階層を使用して、ベンダーをどの程度深く評価するか、関係をどのくらいの頻度で見直すか、どの最小限の管理策を適用するかを決定します。
3. アクセスが許可される前にセキュリティ要件を設定する
ベンダー評価は、アクセスが承認される前に企業が最低限の要件を把握している場合に最も効果を発揮します。
高リスクベンダーの場合、これらの要件は、データを保護し、アクセスの責任を明確にする管理策を対象とすべきです。MFA、転送中および保存時の暗号化、役割ベースのアクセス制御、監査ログ、インシデント対応手順、脆弱性管理、サブプロセッサー管理、データ削除の約束、事業継続計画などです。
セキュリティ証拠はそのレビューをサポートできます。ISO 27001、SOC 2、英国のCyber Essentialsなどの国家スキーム、ペネトレーションテストの概要、またはセキュリティホワイトペーパーは、ベンダーの役割と関係の機密性に応じて、すべて役立つ可能性があります。
認証と監査レポートは、ベンダーがどのように運営されているかを説明します。ベンダーが実際に誰であるかについては、ほとんど語られません。最近のPassworkの安全性に関する調査は、この区別が重要であることを証明しています。欧州の登録、洗練されたウェブサイト、そして”信頼のために構築された”というメッセージだけで、導入するコードの所有権、管轄、起源を追跡したことのない組織の基準をクリアするのに十分でした。
機密アクセスを保持するベンダーについては、管理チェックリストと並んで2つの質問があります。誰が会社を所有し管理しているのか、どの国の法律の下で運営されているのか。そして、独立した専門家がコードを検査できるのか、それとも企業がベンダーの言葉だけを信じてクローズドシステムを信頼しているのか、です。
中リスクベンダーは、より軽いレビューで済む場合がありますが、それでも、アカウントをどのように保護し、従業員のアクセスを制限し、データを扱い、インシデントを顧客に通知し、関係終了時にアクセスを削除するかを説明できる必要があります。
低リスクベンダーの場合、主な確認事項は、機密システムや個人データに本当にアクセスできないかどうかです。それが変わった場合、ベンダーを再評価する必要があります。
優れたプロセスは、リスクが高い場合は厳格で、リスクが本当に低い場合は軽量です。すべてのサプライヤーレビューをエンタープライズ監査にするべきではありませんが、機密アクセスが信頼だけで承認されるのを防ぐべきです。
4. オンボーディング後にベンダーを監視する
ベンダーは、システム、サブプロセッサ、ポリシー、人員配置、セキュリティ管理策を変更します。また、時間の経過とともに、自社がベンダーに付与するアクセス権限が増えることもあります。監視を行わなければ、当初の評価は陳腐化します。
実用的な監視プロセスには、高リスクおよび中リスクのベンダーに対する年次レビュー、契約更新前のチェック、アクセス拡大時の再評価、インシデント報告後のレビューを含めることができます。重要なベンダーでは、より頻繁なアクセスチェックが必要になる場合があります。
監視には認証情報の層も含めるべきです。ベンダーのアカウントが現在も有効な担当者に属しているか、権限が現在の範囲と一致しているか、共有認証情報がまだ存在するか、統合やAPIキーがまだ必要かを確認します。
ここで多くの企業が回避可能な露出リスクを見つけます。古い代理店アカウント、未使用の外部委託先ログイン、誰も管理していない共有パスワード、過去のプロジェクト用に作成された統合、便宜上付与された管理者権限などです。
ベンダーリスクは事業継続計画にも関係します。重要なサプライヤーが利用できなくなったり、侵害を報告したり、緊急のアクセス変更を余儀なくされたりした場合、事業は重要な業務を継続する手段を必要とします。Protonの事業継続戦略ガイドでは、特にアクセスと認証情報が関わる場合に、レジリエンスがバックアップだけに依存しない理由を説明しています。
5. サードパーティの認証情報を管理する
多くのベンダーリスクプログラムは表面上は堅牢に見えても、認証情報のレベルで失敗します。ベンダーは書類上は準拠しているように見えても、日々のアクセス方法によっては依然として露出を生み出す可能性があります。
リスクは、正式なプロセスと現実的なプロセスの間のギャップに存在します。承認されたシステム外に保管された認証情報、明確な所有者がいない共有アカウント、ベンダー関係の変更後も有効なままのAPIキーなどです。
これらのアクセスパスがレビューされず、失効されないままだと、当初の業務が終了したずっと後まで、事業がベンダーリスクを抱え続ける可能性があります。
サードパーティのアクセスは、内部アクセスと同じ規律に従い、同じパスワードポリシーを使用する必要があります。
- ベンダーには必要なアクセス権限のみを付与する
- 可能な限り、個人アカウントを使用する
- 代替手段がない限り、共有認証情報を避ける
- 共有認証情報は、管理された認証情報管理システムに保管する
- ベンダーとファイルを共有する際は、メール添付ではなく、有効期限付きリンクを利用できる暗号化された法人向けクラウドストレージを使用する
- アクセスを定期的にレビューする
- 業務が終了したらアクセスを失効させる
- ベンダーの担当者変更やインシデント発生後に認証情報をローテーションする
- サービスが対応している場合は常にMFAを必須にする
法人向けパスワードマネージャーを使えば、これらのルールを簡単に実装できます。チームは、ベンダーの認証情報を安全に保管し、チャットやメールでパスワードを送信せずにアクセスを共有し、パスワードをローテーションし、ベンダー関係が終了したときにアクセスを削除できます。
ベンダーセキュリティチェックリスト
ベンダーセキュリティチェックリストは、新しいベンダーを安全にオンボーディングするのに役立つはずです。
これを使って、関係を明確に理解しましょう。
- ベンダーはどのようなデータにアクセスし、処理し、保管しますか？
- ベンダーは当社に代わって個人データを処理しますか？
- ベンダーはデータ処理契約（DPA）に署名し、契約終了時に当社のデータを削除しますか？
- データはどこに保管され、処理されますか？
- ベンダーはサブプロセッサを使用していますか？
- ベンダーはMFAを必須にしていますか？
- ベンダーは従業員による顧客データへのアクセスをどのように管理していますか？
- 当社は役割ベースの権限を割り当てることができますか？
- アクセスを即座に削除できますか？
- ベンダーは監査ログや管理者アクティビティレポートを提供していますか？
- ベンダーはデータをどのように暗号化していますか？
- ベンダーはセキュリティインシデントをどのくらい迅速に通知しますか？
- ベンダーには事業継続や災害復旧の手順がありますか？
- ベンダーはセキュリティ文書、認証、監査概要を提供できますか？
- ベンダーは公表されたセキュリティインシデントを経験したことがありますか？また、どのように対応しましたか？
- 会社を所有し管理しているのは誰で、どの法域で事業を行っていますか？
- 製品はオープンソースであるか、独立した監査を受けているため、そのセキュリティに関する主張を検証できますか？
チェックリストは、自社が受け入れているリスクを示す必要があります。正式な認証がないベンダーでも、低リスクの業務には適している場合があります。管理者アクセス、弱い認証、曖昧なインシデント対応期限、明確な削除プロセスがないベンダーは、まったく別の判断になります。
すでに利用しているベンダーについては、更新時や定期的なレビューの際にチェックリストを再度使用します。当初の承認は、現在のツールの使われ方を反映していない可能性があります。小規模なプロジェクトのために導入したベンダーが、気づかないうちに顧客業務、財務ワークフロー、重要な統合の一部になることがあります。
Proton Pass for Businessがベンダーのアクセス制御をどのようにサポートするか
サードパーティのアクセスが管理されたシステムの外で管理されていると、ベンダーリスク管理ははるかに難しくなります。ベンダーが承認され、文書化され、契約でカバーされていても、実際の露出は日々のアクセスパスに依存することがよくあります。具体的には、共有認証情報、権限、パスキー、回復用コード、APIキー、および関係の変化に応じてレビューまたは削除する必要があるアカウントです。
Proton Pass for Businessのような法人向けパスワードマネージャーは、企業がそのアクセスをより安全で監査可能なプロセスに移行するのに役立ちます。チームは、ベンダーの認証情報をエンドツーエンド暗号化された保管庫に保管し、強力でユニークなパスワードを生成し、自動入力を使って手作業を減らし、パスキーを管理し、メール、チャット、プロジェクト文書でパスワードを送信せずにアクセスを共有できます。
特にベンダーアクセスでは、共有保管庫によって認証情報をサプライヤー、プロジェクト、チーム、機密度ごとに分けることができます。これにより、アクセスを整理し、誰が何にアクセスできるかをレビューし、契約終了時、ベンダー担当者の変更時、またはインシデントで迅速な封じ込めが必要なときにアクセスを削除することが容易になります。
ITチーム向けパスワードマネージャーは、プロセスがより正式になるにつれて必要となる管理レイヤーを追加します。ポリシー、レポート、ログ、役割ベースのアクセス制御、SCIMプロビジョニング、シングルサインオン統合により、企業は個人の習慣に頼るのではなく、チーム全体で一貫してアクセスを管理できます。
Proton Pass for Businessは、ベンダーが自社との業務に使用する認証情報とアクセスパスを管理することで、事業をサポートします。また、オープンソースで独立した監査を受けているため、自社のベンダーに適用するよう推奨している同じチェックリストを満たします。サプライヤーのアクセスが管理された環境で保管、共有、レビュー、失効されると、ベンダーリスクは初期評価以降も管理しやすくなります。
法人向けパスワードマネージャーで、サードパーティの認証情報へのアクセスを安全に管理しましょう。
