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

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

はじめに
設計パターンのカタログ
付録
リソース — 外部
リソース — Salesforce
セキュリティに関する考慮事項
イベント駆動型アーキテクチャ
PDF

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

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

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

リバースプロキシサーバ

「リバースプロキシは、Web サーバの前に配置され、それらの Web サーバにクライアント (Web ブラウザなど) の要求を転送するサーバです。リバースプロキシは通常、セキュリティ、パフォーマンス、および信頼性を向上させるために実装されます。」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 「What Is a Reverse Proxy?」、Cloudflare、最終アクセス日: 2019 年 4 月 11 日、https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/。
2 「リバースプロキシ」、Wikipedia、最終アクセス日: 2019 年 4 月 11 日、http://en.wikipedia.org/wiki/Reverse_proxy。