データ流出やデータ喪失は、時間と費用を必要とする事態となり、経済的損失、ブランドイメージの低下、プライバシー重視の法律による罰則などを引き起こす可能性があります。たとえば、北米の電力会社の産業用制御システムから、機密性の高いスマートグリッドやメーターの研究開発知識情報が、ネットワーク内部からの侵入と疑われる攻撃によって流出した事件がありました。公益事業会社からのデータへの不正アクセスは、スマートグリッドの侵害や停電につながる可能性があります。
別の例では、セキュリティ研究者が テスラのバックアップゲートウェイで、公開状態で未知の（ドキュメント化されていない）APIエンドポイントが、データのエクスポートや不正な変更に使用されている可能性があることを指摘しました。もし、この未認証のAPI エンドポイントが攻撃者によって使用され、バッテリーや接続された電力網に損害を与えた場合、現実的で重大な事態が十分に起こりえたのです。
どちらの例も、データ流出からネットワークを保護する方法を考える際に、内部および外部の脅威を考慮することの重要性をはっきりと示しています。インサイダー脅威は、必ずしもユーザーが故意に危害を加えているとは限りません。Fortinetの2019 Insider Threat Reportによると、調査対象の組織で、71%が不注意なユーザーが偶発的な侵害を引き起こすことに懸念があり、65%が悪意なくユーザーがポリシーを無視することを心配しています。2020年にTwitterのハッキングに成功し、著名な人のアカウントへアクセスした攻撃者は、まずは従業員に対するソーシャルエンジニアリング攻撃から始めています。その後、内部管理ツールに移動して、顧客に代わって投稿したり、電子メールや2FAを変更したりするなど、アカウントの設定変更を行いました。
一見すると単なるビットコイン詐欺のように見せかけ、攻撃者は7つのアカウントからデータをダウンロードし、流出させたのです。ヴィッシング（音声によるフィッシングを利用したソーシャルエンジニアリング攻撃）により社内ユーザーのアカウントの安全性が損なわれた場合、ハードキーの追加や管理ツールへのきめ細かいアカウント権限の導入を行えば、攻撃者の手は届かなくなるでしょう。セキュリティウィークの後半では、Twitterのハッキングについてアカウントを乗っ取る攻撃の観点から説明し、その危険性をどのように軽減してきたかを解説しています。
高度な技術や分かりにくいツールがなくても、データの流出は行えます。フィッシングされたユーザーと、アカウントではなくエンドポイントにおける行き過ぎた許可ポリシーの両方があれば、攻撃者はデータを流出させるのに必要なアクセスを手に入れることができてしまうのです。電子メール保護ソリューションで悪意のあるドメインをブロックすること。これはソーシャルエンジニアリング攻撃への対応に、多くのセキュリティチームが信頼を寄せている手順の1つです。しかし、悪意のあるリソースが、外部ソースから内部ソースへではなく、横方向に共有される場合はどうでしょうか。悪意のあるドメインは、チャットなど電子メール以外の通信手段で社員間で共有される可能性があります。そのため、セキュリティチームが社内のユーザーやデータを保護する際に不利となるギャップが生じてしまいます。
私たちは防止と監視のための多層的なアプローチを常に重視しています。社内ツールについては、ロールベースとリスクベースのアクセス制御を行っています。認証の上にさらに認可のレイヤーを追加するために、Accessの後にアプリケーションを置いています。Accessの後にSaaSアプリケーションを追加することで、オンプレミスかクラウドかにかかわらず、ユーザーが必要とするものすべてに安全な接続が可能となります。Accessでは、リモートワークの従業員に対して、場所、デバイスの種類、デバイスの状態、多要素認証 (MFA)に基づいたポリシーを設定することができます。VPNを使用しない環境へ移行する際、Accessが安全なトンネルとして機能します。当社の検出・対応チームは、AccessログとSaaSアプリケーションログの両方を監視し、異常の有無を確認します。近々、SaaSアプリケーション内のAccessログを追加し、ログの充実化とコンテキスト化をさらに進める予定です。
Cloudflareを利用したエンドポイントの保護には、ポリシーを実施するためのクライアントも含まれます。ゲートウェイファイアウォールルールは、Accessと併用することで、L4レイヤー（ネットワーク）とL7レイヤー（HTTP）でより全体的なアプローチをとることができます。ゲートウェイの位置を利用して、悪意のあるドメインへのDNSクエリーを制限しています。
従業員がリモートで勤務している場合、企業はオフィスのエグレスポイントでネットワークポリシーを適用することができません。WARPデスクトップクライアントとGatewayをユーザーのエンドポイントで使用することにより、セキュリティチームはDNSログを可視化することができ、プライバシーを保護しながら、それまで企業オフィスで使用できたポリシーを実施することが可能になりました。ゲートウェイは、企業デバイスのDNSリゾルバとして機能します。これにより、インシデントへの対応と根本原因の特定をさらに効率的に行えるだけでなく、悪意のあるドメインにアクセスし安全性が損なわれたマシンを特定することで、防止にも役立てることができます。WARPは、DNSトラフィックを確実に暗号化し、ユーザーのプライバシーを保護します。
ブラウザ分離ツールは、ユーザーに最も近いレイヤーで、ユーザーがクラウドベースのアプリケーションにアクセスする際に最も長い時間を過ごす場所の保護を実現します。それは防止と対応の両面で大きく役立ちます。特定のSaaSアプリケーションへのアクセスの削除、ユーザーによるコピー＆ペーストの防止、印刷の制限、ファイルのダウンロードのブロックなどに使用できます。つまりクラウドサービスでホストされているデータは、複数の重要なポイントで保護されているので、流出をさらに困難にできるのです。ポリシーを使用し、ドメイン、ユーザー、幅広いカテゴリのWebサイトそれぞれに対して、ブラウザの分離を設定することができます。また、ブラウザの分離により、既知の悪意のあるドメインにアクセスしたり、ブラウザ経由で特定のファイルをダウンロードしたエンドポイントをキャプチャすることで、すでに安全性が損なわれている可能性のあるエンドポイントを迅速に特定することができます。
ここで、Zero Trustモデルが真価を発揮します。この言葉を聞いたことがない方は、こちらの概要をご覧ください。Cloudflare Accessは、組織のネットワークへZero Trustモデルを実装する際に便利なCloudflare Oneツールの重要な一部です。内部リソースのポリシー統一を図るため、Cloudflare Accessを利用して管理しています。私たちは、全社的なアクセス変更を必要とするインシデントの検出・対応チームのセキュリティエンジニアとして、Cloudflare AccessおよびSaaSアプリケーション向けCloudflare Accessによって、アプリケーションレベルの変更にとらわれず効率的にポリシーを推し進められ、より優先度の高い項目に集中できる立場にあります。個別に管理しなければならないアプリケーションのアクセスを一元管理することで、対応に要する時間が劇的に改善されました。
APIレイヤーに目を移すと、CloudflareのAPI Shieldは、APIのセキュリティ制御を管理する主要なポイントとしての機能を果たしています。テスラのゲートウェイのように、多数のAPIを介して公開されているIoTデバイスについてはどうでしょうか。API Shieldは、偶発的なデータ漏洩を抑制するための多層的なアプローチが可能です。例えば、スキーマを検証して、下流のシステムが予期せぬ入力によって危険にさらされる可能性を最小限に抑えることができます。それはつまり、エンドポイントへのリクエストは、有効なクライアント SSL/TLS 証明書を持つクライアントに制限することができるのです。また、Open SOCKSプロキシなどのソースから来るノイズは、APIが通信すべきではないデバイスや地域からのリクエストとともに、フィルタリングすることが可能です。本日の発表では、新しいデータ難読化機能についてもふれています。今週末には、みなさんのセキュリティチームがまだ気づいていない「影の」APIと、異常な呼び出しアクティビティを発見する方法を発表する予定です。
セキュリティの問題から、こうしたシステムのアクセス方法をその場で理解しなければならないケースは、検出・対応エンジニアとして何度も経験してきました。システムによって管理方法が異なり、役割分担も一様ではありません。そのため、即座の対応が非常に難しく、システムオーナーと会話をしてアクセスを理解する必要があるケースが大多数です。Cloudflare One、ブラウザ分離、API Shieldが提供する多層保護を使用することで、セキュリティチームは対応よりも防止に集中できるようになります。