この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

インテグレーションのパターンと実践

はじめに
設計パターンのカタログ
付録
リソース — 外部
リソース — Salesforce
セキュリティに関する考慮事項
PDF

セキュリティに関する考慮事項

エンタープライズポートフォリオの有効なメンバーであるためには、関連するセキュリティのメカニズムに基づいてすべてのアプリケーションの作成と統合を行う必要があります。最新の IT 戦略では、社内サービスとクラウドベースのサービスを組み合わせて使用します。

通常、クラウドツークラウドサービスのインテグレーションでは Web サービスと関連する認証に焦点を当てていますが、多くの場合、社内サービスとクラウドサービスを接続すると複雑さが増加します。このセクションでは、セキュリティツール、手法、Salesforce 固有の考慮事項について説明します。

リバースプロキシサーバ

「リバースプロキシサーバは、インターネットを介して侵入を試みる攻撃者から内部のサーバを保護するセキュリティ機能を実行することにより、社内イントラネット上の HTTP サーバ (中略) を保護するためにネットワーク DMZ 内に通常デプロイされるセキュリティデバイスです」。1

これは、「プロキシサーバの一種で、1 つ以上のサーバからクライアントの代わりにリソースを取得します。その後、これらのリソースはクライアントに返されますが、クライアントからはプロキシサーバ自体から返されたように見えます。リバースプロキシは、その関連サーバ (通常は近隣のサーバ) の仲介として機能し、これらの関連する 1 つあるいは複数のサーバから提供されるリソースのみを返します」。2

Salesforce 実装では、このようなサービスは外部ゲートウェイ製品で提供されることが一般的です。たとえば、Apache HTTP、lighttpd、nginx などのオープンソースオプションを使用できます。市販製品には、IBM WebSeal や Computer Associates SiteMinder などがあります。これらの製品は、内部要求者の代わりにすべてのアウトバウンド Salesforce 要求をプロキシおよび管理するように簡単に設定できます。

暗号化

一部の企業では、社内アプリケーションとクラウドベースのアプリケーション間で、選択したトランザクションやデータ項目を暗号化する必要があります。組織で追加のコンプライアンス要件に準拠する必要がある場合は、次のような代替方法を実装できます。
  • Salesforce の CipherCloud、IBM DataPower、Computer Associates など、社内の市販の暗号化ゲートウェイサービス。これらの各ソリューションでは、暗号化エンジンまたはゲートウェイは、暗号化されたペイロードを送信および受信することによってトランザクション境界で呼び出されるか、HTTP 要求を実行する前に特定のデータ項目を暗号化または復号化するために呼び出されます。
  • Salesforce Shield Platform Encryption など、クラウドベースのオプション。Shield Platform Encryption では、重要なプラットフォーム機能を保持しながらデータに新しいセキュリティ層が追加されます。選択したデータは、高度な鍵派生システムを使用して暗号化されます。以前より安全にデータを保護することができます。詳細は、Salesforce オンラインヘルプを参照してください。

特殊な WS-* プロトコルのサポート

セキュリティプロトコル (WS-* など) の要件に対応するには、次の代替方法をお勧めします。
  • セキュリティ/XML ゲートウェイ — WS-Security ログイン情報 (IBM WebSeal または Datapower、Layer7、TIBCO など) をトランザクションストリーム自体に挿入します。このアプローチでは、アプリケーションレベルの Web サービスまたは Salesforce からの Web サービスの呼び出しを変更する必要はありません。また、Salesforce インストールでこのアプローチを再利用することもできます。ただし、既���のセキュリティゲートウェイアプローチへの適切な WS-Security の導入を管理するには、追加の設計、設定、テスト、メンテナンスが必要になります。
  • 伝送レベルの暗号化 — 双方向 SSL および IP 制限を使用して通信チャネルを暗号化します。このアプローチでは、WS-* プロトコル自体を直接実装することはありませんが、ユーザ名とパスワードを渡すことなく、社内アプリケーションと Salesforce 間の通信チャネルを保護します。また、Salesforce で生成されるクラスを変更する必要もありません。ただし、(アプリケーション自体またはミドルウェア/ESB レイヤで) 一部の社内 Web サービスを変更する必要が生じる場合もあります。
  • Salesforce カスタム開発 — WSDL2Apex ユーティリティを使用して WS-Security ヘッダーをアウトバウンド SOAP 要求に追加します。これにより、内部サービスを呼び出す WSDL ファイルから Java のような Apex クラスが生成されます。DMZ 内のバックエンド Web サービスまたは追加コンポーネントを変更する必要はありませんが、次のことが必要になります。
    • 構築およびテスト作業の増加
    • WS-Security 属性のコードを手動で作成するための比較的複雑��手動プロセス (Apex コード内の XML 逐次化など)
    • より高度な長期メンテナンス作業

    最後のオプションは複雑でリスクが高く、このようなインテグレーションは Salesforce の定期更新に基づいて定期的に確認する必要があるため、お勧めできません。

    メモ

1 「リバースプロキシサーバとは」、IBM Corporation、最終アクセス日: 2012 年 4 月 11 日、http://publib.boulder.ibm.com/infocenter/sametime/v8r5/index.jsp?topic=%2Fcom.ibm.help.sametime.v851.doc%2Fconfig%2Fst_adm_port_rvprxy_overview_c.html。
2 「リバースプロキシ」、Wikipedia、最終アクセス日: 2012 年 4 月 11 日、http://en.wikipedia.org/wiki/Reverse_proxy。