Hyperforce の IP 許可リスト登録の望ましい代替案

Hyperforce の接続を保護するためサポートされている手法は、次のとおりです。

双方向の接続の保護

• Mutual TLS (mTLS) を実装する
• Salesforce プライベートコネクトを使用する

お客様のネットワークから Salesforce への接続

• ドメイン許可リスト
• Service Name Indicator (SNI) を使用する
• 認証プロバイダを使用する (任意)
• 接続アプリケーションを使用する

各手法の利点と詳細については、下記を参照してください。

双方向の接続の保護

Mutual TLS (mTLS) を実装する

Transport Layer Security (TLS) は、クライアントからサーバーへの安全なリンクを確立する暗号化ベースの接続プロトコルです。Mutual TLS (mTLS) はさらに、サーバーからクライアントへの安全なリンクも確立します。接続確立前に双方のエンティティの証明書を検証することで、mTLSは強化されたセキュリティを提供します。mTLS を導入されたお客様は、自身が Salesforce に接続していること、およびその逆も絶対的に確信できます。mTLS は、ドメインおよび IP ベースの許可リストの代替手段として、あるいはそれらと組み合わせて使用できます。
 

リソース

• 外部システムの認証設定
• 証明書による双方向 SSL 認証
• アウトバウンドメッセージでの Salesforce クライアント証明書の使用

Salesforce プライベートコネクトを使用する

Salesforce と AWS (Amazon Web Services) インスタンス間の通信にパブリックインターネットを使用しないことを希望するお客様は、Salesforce プライベートコネクトを購入できます。Salesforce プライベートコネクトは、Salesforce 組織と AWS アカウント間の完全管理型双方向プライベート接続を提供するネットワークサービスです。お客様は Amazon の PrivateLink を利用することで、Salesforce 組織を AWS 上で稼働する仮想プライベートクラウド (VPC) 内のリソースに簡単に接続でき、より安全な API 統合を実現できます。すべてのトラフィックは専用接続経由でルーティングされ、トラフィックやお客様の VPC がパブリックインターネットに公開されることは一切ありません。

プライベートコネクトでは、Salesforce のみが顧客のエンドポイントにコールすることが保証されるため、IP 許可リストよりも安全です。プライベートコネクトを理解するための一般的な例えとして、電話とトランシーバーを比較すると分かりやすいでしょう。電話は誰でも発信できるため、迷惑電話を防ぐには許可/拒否リストを常に監視して調整する必要があります。これはIP許可リストの管理と類似しています。一方トランシーバーでは、2台の端末が専用接続で結ばれるため、リスト管理は不要です。Private Connectはトランシーバーと同様で、Amazon Resource Name (ARN) と呼ばれる固定の AWS ID で特定された発信者のみが接続を許可されます。

プライベートコネクトは Sales Cloud、Service Cloud、CRM Analytics、Data Cloud で使用できます。

リソース

• Sales Cloud と Service Cloud (コア) および CRM Analytics: プライベートコネクトを使用したクロスクラウド連携の保護
• Data Cloud: Data Cloud 向けプライベートコネクト

お客様のネットワークから Salesforce への接続

ドメイン許可リスト

Salesforce からお客様のネットワークへの接続では、ドメイン許可リストはサポートされていません。

お客様のネットワークから Salesforce への接続では、IPを許可リストに登録する代わりに、 *.force.comなどの Salesforce ドメイン名を許可リストに登録できます。ドメイン名の許可リスト登録は一般に簡単に実装でき、ドメイン名が変更されることはほとんどありません。
 

リソース

• 必要なドメインを許可
• Domain Name System Security (ドメイン名のシステムセキュリティ)

Service Name Indication (SNI) を使用する

Service Name Indication では、クライアントまたはブラウザが接続するホスト名を指定できるようにすることで、Transport Layer Security (TLS) プロトコルを拡張します。これはサーバーが同じ IP アドレスで複数の証明書を提示する可能性があるため、重要です。一般的なたとえとして、マンションの住人に荷物を発送する状況を考えると、SNI を理解しやすくなります。TLS ではパッケージが適切な住所に送信されることが保証され、SNI ではパッケージがその住所の適切な部屋に送信されることが保証されます。

Hyperforce では、各 Salesforce ドメインに個別の HTTPS 証明書があります。SNI がない場合、Hyperforce はすべての *.my.salesforce.com と *.sandbox.my.salesforce.com ドメインをサポートするデフォルトの証明書を返しますが、他のドメインに宛てるには、Web ブラウザと API 呼び出し側が ClientHello メッセージに SNI を含めて目的のドメインを指定する必要があります。デフォルトのドメインに宛てる場合でも SNI を送信することが推奨されます (詳細については、「Hyperforce における SNI による HTTPS/SSL 接続エラーの解決」を参照)。

お客様のネットワークから Hyperforce への安全な接続を確立するため、お客様のネットワークインフラストラクチャが SNI ヘッダー検査をサポートしているかどうかを調査することをお勧めします。 SNI ヘッダーを検査することで、トラフィックを確実に自社の Salesforce 環境に送信できます。

SNI には次のような利点があります。

• 精度: すべてのトラフィックが正しい宛先にルーティングされることを保証する
• 簡便性:お客様が共通プロトコルに拡張を加える
• スケーラビリティ: 特に IPv4 を使用する場合、顧客が接続できる数を拡張する
• セキュリティ: 接続は IP 許可リストよりも安全性の高い TLS に基づく

リソース

• TLS 1.2、SNI の有効化の概要
• カスタムドメイン要求で Server Name Indicator (SNI) 拡張を含める
• Hyperforce における SNI による HTTPS/SSL 接続エラーの解決
• Include SNI Extension for Custom Domains using Salesforce Cloud option with Salesforce Edge Network (Salesforce Edge Network で Salesforce Cloud オプションを使用してカスタムドメインの SNI 拡張子を含める)

認証プロバイダを使用する (任意)

Github や Okta などの認証プロバイダを使用して Salesforce 環境にアクセスするお客様の場合、Salesforce で認証アプリケーションを管理します。

このオプションでは、お客様が認証プロセスを選択して制御できますが、Salesforce の要件ではありません。
 

リソース

• 認証プロバイダ
• Salesforce が管理する認証プロバイダの使用
• Salesforce 認証プロバイダーの設定
• 内部ユーザーのシングルサインオンの設定

接続アプリケーションを使用する

外部のアプリケーションから Salesforce にアクセスする必要がある場合は、接続アプリケーションを使用します。接続アプリケーションフレームワークにより、API や SAML (Security Assertion Markup Language)、OAuth、OpenID Connect などの標準プロトコルを使用して、外部アプリケーションと Salesforce を統合できます。接続アプリケーションはこれらのプロトコルを使用して、外部アプリケーションの認証と承認を行い、シングルサインオン (SSO) を提供します。接続アプリケーションは API 統合によるデータへの安全なアクセス、サービスプロバイダと Salesforce の統合、外部 API ゲートウェイの認証、サードパーティアプリケーションへのアクセス管理を実行できます。
 

リソース

• 接続アプリケーションの使用事例
• 接続アプリケーションの作成
• 外部 API ゲートウェイの OpenID Connect 動的クライアント登録

関連情報

• Hyperforce について - 一般情報と FAQ
• Hyperforce 上の Salesforce サービスへの中断しないアクセスを維持する
• 許可すべき Salesforce の IP アドレスとドメイン