fbpx

IPアドレスベースのアクセス制御を変革する

好きな所から読む

多くの企業は、アプリケーションへのアクセスを制御するためにソースIPアドレス識別を採用しています。ただし、これらの組織がSaaSアプリケーションを採用し、内部アプリケーションをデータセンターから移行し、リモート作業をサポートする場合、企業リソースへのアクセスを保護する手段としての送信元IPアドレスの識別の効果は低くなります。

作業方法は、クラウドファースト、デバイスにとらわれず、リモートに進化しました。それを保護する手段も進化しなければなりません。エンタープライズクラウドの変革には、新しいIDベースの承認メカニズム(多要素認証、MFAなど)が必要です。

一部の組織では、IPアドレスのみからインラインプロキシセキュリティを使用するMFAへのパスに高いスイッチングコストがかかります。IPアドレスコントロールは、レガシーアプリケーションにハードコードされているか、地理的制限として内部Webサイトに埋め込まれているか、規制要件によって義務付けられているか、または単に企業のITセキュリティ文化に深く根付いている場合があります。

ユーザーの作業の大部分は現在、クラウドまたはインターネット上で行われ、多くの場合、「ホットスポット」から、および/または個人のデバイスからリモートで行われています。送信元IPアドレスの識別は、それ自体では、エンタープライズリソースへのアクセスを管理するための信頼できる、または強制可能なセキュリティ制御ではなくなりました。

IPアドレス制御の履歴・制限

IPアドレスに基づいてアプリケーションまたはリソースへのアクセスを制限することは、ユーザーとアプリケーションの両方が境界防御の範囲内にいた時代からのコントロールコンセプトです。IPアドレス番号は、企業ネットワーク経由でアプリケーションまたはリソースへのアクセスを求めるホストデバイスを識別します。セキュリティの「チャレンジ」は基本です。このデバイスのIPアドレスは、数値の許容可能な設定範囲内ですか?はいの場合、跳ね橋を下げます。いいえの場合、玄関の呼び鈴に答えないでください。

このようなエンタープライズ環境では、IPアドレスはいわゆる「セキュリティゾーン」に分類され、各ゾーンにはセキュリティ感度のレベルが割り当てられています。エンタープライズデバイスは、特定のゾーンに与えられた特権に基づいてリソースにアクセスできます。ゾーンの範囲は不連続である可能性があり、一部のホストデバイスはデフォルトのセキュリティゾーンに割り当てられている可能性があります(インターフェイスが既存のセキュリティゾーンにまだ明示的に関連付けられていない場合)。

IPアドレス制御は、ホワイトリストとブラックリストに依存しています。アクセスを許可するために、アプリケーションまたはサービスは、問い合わせデバイスのソースIPアドレス番号を、「ホワイトリスト」としても知られる承認済みの番号リスト(たとえば、許可されたセキュリティゾーン内)と比較し、比較の結果に基づいて、アクセス要求を拒否、またはチャレンジします。要求された場合、ホストデバイスは追加の認証詳細を提供する必要がある場合があります。(レガシーデータセンター環境では、このようなチャレンジ機能は典型的ではありません。アクセスは通常IPアドレスのみで決定されます。)ホストデバイスが拒否された場合、その数はブラックリストに記載されます。(ブラックリストは他の方法でも機能することに注意してください。ITセキュリティは、実際のまたは知覚されるセキュリティリスクのために、宛先として特定のURLまたはIPアドレス範囲へのアクセスを制限する場合があります。)

ソースIPアドレスベースのアクセス制御は、実装がかなり簡単です。それらだけで効果があったとすれば。新しいエンタープライズの作業方法を保護することに関しては、ソースIPアドレスベースのアクセス制御には制限があります。

  • 不十分な認証:識別メカニズムとして、IPアドレスコントロールはデバイスのユーザーではなくデバイスを認識します。これにより、ゼロトラストポリシーの主要コンポーネントである最小特権のアクセス許可が適用されなくなります。承認されたセキュリティゾーン内のデバイスが侵害された場合、そのデバイスにアクセスできるすべてのものが攻撃に対して脆弱になります。
  • 複雑さ:IPアドレス管理は非常に複雑です。不適切に設定されたIP範囲は、管理サイトへのアクセスを誤ってロックアウトする可能性があります。
  • リモートでの作業には効果がありません:地理的制限(たとえば、地理に基づいて割り当てられた特定の範囲)に使用すると、ユーザーが新しい「地理的外」の場所からリソースにアクセスすると、ソースIPアドレスの制御が失敗します。
  • パフォーマンスの低下:ソースIPの制限により、ユーザーはリモートの作業場所からVPNに強制的にアクセスするため、既知のIPを介してインターネットに下りることができます。このバックホールにより、レイテンシが増加します。そもそも本来、境界型の延長であるVPNはゼロトラストへの移行が必要です。
  • 侵害の脆弱性:IPアドレスは簡単に偽装される可能性があります。一般的な攻撃ベクトルシナリオの1つ:許可されたアドレススペース内のオープン(または弱いWEP暗号化ベース)Wi-Fiネットワークは、接続を乗っ取ってアクセスするために簡単に悪用される可能性があります。

ソースIPアドレスを「アンカー」してアプリケーションやリソースへのアクセスを制御する企業は、新しいクラウドファーストデバイスに依存しないテレワークの作業方法を保護するためのアプローチを再発明する必要があります。実際、彼らの従業員は既にそのように働いています。しかし、アクセスを保護する唯一の手段としてソースIPアドレス制御を超えることは簡単ではなく、そのような努力はスイッチングコストを招く可能性があります。

クラウドベースのセキュリティサービスは、ソースIPアドレスのセキュリティアンカーと組み合わせて、クラウドセキュリティサービススタックのレイヤーとして機能し、企業の脅威保護態勢を強固にすることができます。より強力なセキュリティアーキテクチャへの移行パスを提供します。

ソースIPコントロール:レイヤードセキュリティへの実用的なアプローチ

クラウドとモビリティが従来のネットワークとセキュリティアーキテクチャを混乱させるという考えに基づいて設立されました。この混乱は、企業がソースIPアドレスベースのセキュリティ制御からアイデンティティベースの認証に移行する必要があることから明らかです。

新しい作業方法を保護するには、企業のITリーダーは評価から始める必要があります。組織は、アクセス制御メカニズムとして送信元IPアドレスにどの程度依存していますか?何既存の理想的なセキュリティ状態の間のギャップは?また、このようなイニシアチブを社内で販売するのに役立つ評価基準(コスト、複雑さ、セキュリティポスチャメトリックの改善)はどれですか。

その評価は、エンタープライズセキュリティ戦略計画の最初の段階です。

    1. ソースIPアドレスの使用を監査して、内部および外部リソースへのアクセスを許可/制限します。
      1. ソースIPアドレス制御の使用を変更できますか?もしそうなら、何(ケースバイケースで)それらの変更の範囲は?
      2. 承認されたセキュリティゾーンのIPアドレスは、外部のサードパーティ(IPアドレスを使用して地域内のアクセスを決定する政府の規制機関など)によって義務付けられていますか?
      3. レガシーIPアドレスコーディングが埋め込まれた内部サイトを、MFAなどのより新しい(動的な)認証メカニズムに更新できますか?
    2. 評価結果に基づいて、セキュリティの移行に優先順位を付けます。
      1. ソースIPアドレスの制御:インラインプロキシクラウドベースのセキュリティでどのエンタープライズオペレーションを階層化する必要がありますか?

ユーザーのインターネット下りを保護し、企業を外部の脅威(フィッシングランサムウェア、またはその他のマルウェア攻撃)とデータの漏洩の両方から保護します。また別の製品でアプリケーションとリソースへの内部トラフィックを保護し、企業データへの不正アクセスから企業を保護することも可能です。2つのサービスは個別に販売および管理されます。

ソースIPアドレスベースの制御

企業は、従来のインターネット下り方式からローカルインターネットのブレイクアウトへと進みます。従来のモデル(城と堀の境界セキュリティを備えたハブアンドスポークの企業ネットワーク)では、ユーザーは(多くの場合VPNを介して)中央のWebゲートウェイに接続し、そこからインターネットに移動します。トラフィックがバックホールされ、ゲートウェイがボトルネックになり、接続パフォーマンスが低下します。

ユーザーが最寄りのインターネットオンランプでオンラインになり、Office 365などのSaaSアプリケーションを含むインターネットリソースへの直接、安全、高速、最適化されたアクセスを楽しむモデルとは対照的です。この新しいモデルでは、企業ネットワーク(およびインターネット)はなくなります。インラインプロキシとして機能します。お客様のデバイスまたはネットワークからの元の接続を終了し、ユーザーに代わって宛先コンテンツサーバーへの新しい直接接続を開始します。コンテンツサーバーに表示されるソースIPアドレスは、データセンターからのパブリック出力IPアドレスであり、エンタープライズユーザーのデバイスの元のIPアドレスではありません。

クライアントからサーバーに行き来するすべてのコンテンツを検査し、ユーザーが悪意のある(または侵害された)宛先にアクセスした場合にユーザーを保護できます。出力でIPを使用すると、ネットワークアドレス変換(NAT)保護の形式として機能し、デバイスのIPアドレスを宛先コンテンツサーバーから保護します。(デバイスのIPアドレスがXFFヘッダーに挿入されることに注意してください。)

送信元IPアドレスのホワイトリストに依拠している企業の場合、宛先アプリケーションはIPアドレスを許容可能な「セキュリティゾーン」の範囲内として認識しないため、NATアドレスマスキングはアプリケーションアクセスを妨害する可能性があります。

企業トラフィックを内部リソースに誘導します。接続は出力されませんが、代わりにアプリケーションコネクターにルーティングされます(そこから適切な内部リソースに接続されます)。アプリケーションコネクタはお客様自身のデータセンターまたはパブリッククラウド(たとえば、AWS、Azure、またはGCP)に存在するため、宛先リソース(内部アプリケーションやコンテンツサーバーなど)は、ユーザーに割り当てられた、またはホワイトリストに登録されたIPアドレスを表示できます。

非Webアプリケーションのエンドポイントコントロールをし、内部Webアプリケーションに対してブラウザベースのアクセスを可能にします。すべての送受信トラフィック(SSL / TLS暗号化データを含む)の包括的な検査を提供しますが、内部データトラフィックのゼロトラスト原則に準拠しているため、そうではありません。セキュリティをレイヤー化しようとしている企業は、固有のIPアドレスNATを使用する事を検討する必要があります。ソースやIPアドレス制御は、セキュリティ検査を必要としない信頼できるアプリケーションへのユーザーアクセスを保護するためのオプションですが、より広いインターネット下りリスクへの露出の測定を考慮した場合のみです。

安全な導入を確保するための一般的な使用例、主要な考慮事項、およびベストプラクティスの推奨事項を以下に示します。

送信元IPアドレスベースのアクセス制御:従来の使用例

アプリケーションアクセス制御メカニズムとしての送信元IPアドレスは、次の4つの主要なエンタープライズユースケースに分類できます。

  1. 外部SaaSアプリケーションへのアクセスの制御
  2. ステップアップ認証ポリシー属性としてソースIPアドレスを使用する
  3. 境界ファイアウォールでの着信接続の許可/制限
  4. 送信元IPアドレスに基づく地理位置情報

1.外部SaaSアプリケーションへのアクセスの制御

SaaSなどの多くのアプリケーションは、アプリケーションサーバーへのアクセスの承認基準としてIPアドレスを引き続き使用しています。インバウンド接続要求が検出されると、アプリは送信元IPアドレスをホワイトリスト(たとえば、承認された「セキュリティゾーン」の範囲の番号)と比較し、アクセスを許可または拒否します。

多くの場合-ほとんどのSaaSアプリケーションアクセス方法を含めて-この形式のアクセスは通常、アプリケーションレベルの認証に取って代わるものではありませんが、それでもまだ一般的に使用されています。保護されたデータセンターからクラウドまたはインターネットに移行されたアプリケーション(多くの場合、レガシーIP アドレスベースのアクセス制御コードを実行するアプリケーション)の補足アクセスメカニズムとしてエンタープライズ環境で使用できます。

アプリケーションが権限のないユーザーにアクセスを許可しないようにするには、MFAのようなより最新のセキュリティアプローチが必要です。また、ほとんどのSaaSアプリケーションは、シングルサインオン(SSO)とセキュリティアサーションマークアップ言語(SAML)をサポートするようになりました。一部のSaaSアプリケーションでは、ソースIPアドレスはテナントと認証スキームの識別に使用され、サービスが着信接続に使用するテナントとIDプロバイダー(IdP)を選択できるようにするため必須です。

レガシーネットワーク設計では、ロケーションのファイアウォールのNAT境界を通過した後、出力IPアドレスはすべてのカスタマーロケーションのパブリックIPまたはIP範囲になります。 レガシーネットワークでは、比較的少数の下りロケーションとIPがあり、クラウドとパートナーアプリケーションのホワイトリストの管理が管理しやすくなります。 ローミングユーザーがこれらのアプリケーションにアクセスする場合は、VPNでロケーションにアクセスする必要があります。これにより、ユーザーはそのロケーションのIPを介して下り、アクセスが許可されます。

SaaSベンダーは、IDプロバイダー(IdP )がユーザー資格情報をサービスプロバイダー(SaaS)に渡すことを可能にするセキュリティアサーションマークアップ言語(SAML)を広く採用しています。歴史的に、MFAは扱いにくいエンタープライズクラスのソリューションと見なされていました。実装が難しく、展開が困難です。管理は難しく、エンドユーザーは各サービスでトークンを持ち歩く必要がありませんでした。しかし、モバイルスマートフォンの登場により、otpまたはトークンの生成を容易にするアプリケーションが登場しました。さらに、多くのWebアプリケーションでアドオン機能としてMFAが有効になり、管理オーバーヘッドが削減されています。この使いやすさとセットアップの容易さは、このセキュリティ機能の人気の高まりの大きな原動力です。

多くのセキュリティソリューションで、ユーザーのプロビジョニングと認証にSAMLを使用してID管理をデプロイすることを推奨しています。

一部のアプリケーションはオプションのセキュリティレイヤーとしてIPアドレスホワイトリストを提供しますが、一部のサービス(B2Bの状況で一般的)は必須としてソースIPホワイトリストを必要とし、ソースIPアドレスの明示的なリストなしにパートナーをオンボーディングしません。たとえば、A社にはB 社のシステムで作業している請負業者がいて、B 社のシステムにアクセスするために、事前に指定されたIP範囲から接続を開始する必要があります。その他の一般的な例としては、VAT申告アプリケーションなど、政府機関がホストするアプリケーション、ブルームバーグまたはトムソンロイターがホストする研究端末、銀行アプリケーションなどがあります。

2.ステップアップ認証ポリシー属性としてソースIPアドレスを使用する

送信元IPアドレスは、認証の課題をエスカレーションするための決定基準として使用できます。 たとえば、ホワイトリストに送信元IPアドレスを使用するエンタープライズ環境(上記の使用例1を参照)では、送信元IPアドレスが次の場合、単一の認証要素(IPアドレス番号自体)に基づいて許容範囲内で着信デバイス接続が許可されます。しかし、範囲外のIPアドレスのデバイスがアクセスを必要とする状況がある場合、IPアドレスの確認は困難になります。 ソースデバイスのIPアドレスが許容範囲内にない場合、認証の2番目の要素(またはそれ以上)(ワンタイムパスワードまたはRSAキーエントリ)が必要です。

このユースケースは、ホワイトリスト(ユースケース#1)に加えて、認識されないIPアドレスアクセスを許可する追加の認証チャレンジです。その方法では、理論的にはユーザーが新しいデバイスから(もちろん、第2要素認証の検証を使用して)ログオンできるため、リモート作業のサポートがわずかに向上します。ただし、それでも(ユーザーではなくデバイスに関連付けられた)かなり選択的な認証形式です。

3.境界ファイアウォールでの着信接続の許可/制限

一部の企業(アプリケーションまたはデータを内部ネットワークまたはデータセンターからパブリックIaaSクラウドに移行する場合)は、再配置されたアプリケーションをホストする仮想ネットワークへのアクセスを制限しようとします。このモデルでは、ITは基本的に、仮想ネットワークの周囲に境界ファイアウォールを拡張し、城内およびセキュリティで保護されたネットワーク(既知のすべてのセキュリティ制限付き)をクラウドで仮想化します。:インバウンドアクセスは、VPNを介して許可される(VPNへのアクセスは、 もちろん、送信元IPアドレスに基づく)か、または選択した範囲内のホワイトリストに登録されたIPアドレスに基づきます(仮想化ファイアウォールルールセットで構成)。

クラウドで移行され、カスタム開発された内部アプリケーションが「ハード化」されたり、インターネットに公開できる程度にテストされたりすることはめったにありません。リファクタリングは高価であり(常に実用的であるとは限りません)、この使用例では、送信元IPアドレスベースのアクセス制御が(その制限にもかかわらず)重要なセキュリティ機能として(文字通りおよび比喩的に)定着しています。

4.送信元IPアドレスに基づく地理位置情報

一部のWebサイトは、IPアドレスの地理位置情報に基づいて動的コンテンツを表示します。その他-多くのメディアサービスや政府のサイトなど-は、ソースIPアドレスの識別を使用してコンテンツへのアクセスを制限しています。認識される地理位置情報を変更できます。たとえば、カナダのユーザーが国境を越えて近くのサーバーを介してログオンする場合があります。宛先サイトは、再割り当てされたIPアドレスを認識し、米国に所在するデバイスであると考えるものにコンテンツを提示します。

残念ながら、それに依存しているサイトでは、IPアドレスベースの地理位置情報は、特に正確ではなくなっています。

  • 「エニーキャスト」はデバイスの特定を難読化する可能性があります。:IPアドレスプレフィックスが複数の場所から同時にアナウンスされる場合、それは「エニーキャスト」と呼ばれます。これは、CDN、DDoS軽減サービス、およびDNSプロバイダーがトラフィックを宛先にルーティングするためにネットワークホップを最も少なくするために一般的に使用する接続最適化手法です。 しかし、そのプレフィックスは一度に複数の場所にあるように見える可能性があり(見晴らしの点によって異なります)、ソースデバイスを正確に地理的に特定することがほぼ不可能になります。
  • モバイルデバイスはモバイルです。:リモートで作業しているユーザーは移動して接続を維持できます。デバイスの場所が比較的短期間で移動する場合(たとえば、ある都市から別の都市へ電車に乗る場合)、宛先サイト/コンテンツサーバーがIPアドレスを特定の場所に明確に関連付けることは困難です。
  • サブスクリプションデータサービスは、独自のゲートウェイを介してトラフィックをルーティングします。:多くのサービスキャリア(モバイルデバイスプロバイダーなど)は、集中型ゲートウェイをパブリックインターネットへのオンランプとして使用しています。その誤った方向付けにより、宛先サイトが混乱し、ゲートウェイが存在する場所からソースデバイスへのアクセスが行われていると思い込む可能性があります。

GPSのピンポイント設定、セルタワーの三角測量、さらには物理的な請求先住所の相関など、より近代的な手法は、ユーザーの地理位置情報の精度を向上させるのに役立ちます。ただし、これらのオプションは、企業のIT管理者が常に利用できるわけではありません。

ソースIPアドレスアクセスコントロールを備えたセキュリティ対策の採用:ソリューションと導入に関する考慮事項

ソースIPアドレスのアプリケーションアクセス制御を保持する必要がある組織のために、大規模に分散されたインラインプロキシのクラウドベースのエッジサービスは、セキュリティスタックに必要な追加レイヤーを提供します。

独自のIPアドレスを使用することを検討している企業は、複数の潜在的なソリューションアプローチを検討する必要がある

  1. IPアドレスを選択的にホワイトリストに登録する
  2.  XFFヘッダーを活用する
  3. プライベートクラウドインフラストラクチャを使用する
  4. 内部/信頼されたリソースへのアクセスに新たなセキュリティを使用する

1. IPアドレスを選択的にホワイトリストに登録する

クラウドアプリケーションにアクセスするために選択したIP(またはいくつかのデータセンター)をホワイトリストに登録すると、既存のプロセス(またはビジネスロジック、サイトコード)を保持できます。ただし、MFAなどの追加の認証メカニズムを組み込んで、攻撃対象領域をさらに削減します

2. XFFヘッダーを活用する

「XFF」は「x-forwarded-for」Webプロキシ機能です。内部のエンタープライズコンテンツサーバーは、これを使用して、デバイスの元のソースIPアドレスを示します(データが転送されるか、プロキシ経由でルーティングされる前)。すべてのHTTPトラフィックには、デフォルトでXFFが挿入されます。宛先アプリケーションまたはコンテンツサーバーが着信XFFヘッダーを読み取って解釈できる場合、送信元IPアドレスベースのアプリケーションアクセスルールを適用できます。これは上記のユースケース1、2、3を満たし、企業は追加のセキュリティを享受します。

残念ながら、多くのアプリケーションはXFF情報を読み取ったり、それに基づいて動作したりすることができません。さらに、企業がユーザーにローカルインターネットブレークアウトを確立し、アプリケーションへのリモートアクセスを許可すると、IPアドレスが増加し、XFFヘッダーに表示されるIPの数がすぐに管理できなくなる可能性があります。

3.内部/信頼されたリソースへのアクセスに新たなソリューションを使用する

アプリケーションコネクタ(アプリケーションの隣にあるVM)間のポリシー定義のトンネルを介して、ユーザーを内部のプライベート宛先に接続します。

NATを介してエンタープライズデータトラフィックに新しいIPアドレスを割り当てません。トラフィックはクラウドベースのインラインプロキシを経由して移動しますが、そのトラフィックはプライベートのままで、1つの内部ユーザーと内部の宛先(パブリッククラウド内であっても)の間を接続します。技術的には、アプリケーションコネクタはプライベート仮想インフラストラクチャであり、ソースデバイスの出力IPアドレスを使用します。宛先サイトまたはアプリケーションはIPアドレスを認識します(上記の使用例1、2、および3のように許可/制限ビジネスロジックを適用できます)。

4.トラフィックをノースバウンドWebプロキシに転送する

プロキシチェーンを有効にします。これは、企業が既知のソースIPを必要とする特定のトラフィックを選択的に転送しながら、トラフィックをスキャンする機能を維持しながら、別の認証済みWebプロキシ(Squid転送/キャッシュプロキシなど)に転送する機能です。追加の「ノースバウンド」プロキシは、オンプレミスまたはパブリッククラウドにあります。着信HTTP トラフィックを受信し、宛先サイトまたはアプリケーションに送信する前に、受け入れ可能なIPアドレスをデータに割り当てることができます。

データ移動距離が長くなることによる潜在的なパフォーマンスへの影響に加えて、このソリューションは追加のリスクをもたらします:追加されたプロキシは、内部を超えて潜在的な攻撃面の露出を拡大します。これを緩和するために、ノースバウンド出力でのみ追加のプロキシをサポートします。

次のステップ:SAML、MFA、および(最終的には)リファクタリング

アプリケーションへのアクセスを管理するメカニズムとしてソースIPアドレスを使用する必要がある企業は、セキュリティスタックのレイヤーを追加する必要があります。ソースIPアドレスベースのアプリケーションアクセスコントロールを使用してデプロイするための4つのベストプラクティスを推奨しています。

  • SaaSアクセス用のエンタープライズSAML機能を展開します。これは、デバイス認証からユーザー検証への移行に向けた貴重なステップです。
  • すべてのアプリケーションアクセスにMFAを追加します。MAMLはSAMLと相まって、新しい作業方法に不可欠なセキュリティレイヤーを提供し、いつでもどこでもユーザーがSaaSアプリケーションにアクセスできるようにします。
  • ソースIPアドレスの検証が依然として必要なアプリケーションの移行計画を確立します。

レガシー要件またはコンプライアンス要件のため、企業はアプリケーションアクセスに近い将来、ソースIPベースのアクセスを引き続き使用します。

ソースIPからクラウドへのパス

送信元IPアドレスの識別は、企業のデータトラフィックを保護するための信頼できる手段ではなくなりました。このアプローチは拡張できず、簡単に危険にさらされ、リスクを高め、脆弱な脅威の展望を拡大し、企業の新しい作業方法(クラウドファースト、リモート、デバイスに依存しない)を保護しません。

しかし、ソースIPアドレスの制御は、多くの組織でしっかりと定着しています。ある程度のソースIPアドレス制御を維持する必要がある企業向けに、より優れたセキュリティモデルへの説得力のある方法を提供する必要があります。

SNSでもご購読できます。

コメントを残す

*