More than 3 years have passed since last update.

Becoming a Salesforce Certified Technical Architectの要約（3章：コアアーキテクチャの概念-統合と暗号化-）

Salesforce

Posted at 2022-04-07

3章コアアーキテクチャの概念-統合と暗号化-

概要

企業への統合–状況を理解する
一般的な統合スタイルの紹介
さまざまな統合ツールについて話し合う
最新の統合アプローチの調査
暗号化–一般的な概念を理解する
暗号化アルゴリズムのタイプとユースケース

ポイント

統合アーキテクチャ設計の原則
統合スタイルごとの特徴と使用できるツール
最新の統合アプローチ（サービス指向、API主導、イベント駆動）
統合に関するさまざまな種類のツールとメカニズムとツールごとの理想的なユースケース
暗号化に関する概念や暗号化の種類、アルゴリズムごとのユースケース

詳細

Salesforceは企業のビジネス変革プロセスの中心になる
Salesforceは他の数十のアプリケーションと接続する必要がある
適切な統合アーキテクチャを考え出すことがSalesforceプロジェクトを成功するために重要である

企業への統合–状況を理解する

今日の企業には、多数のアプリケーションがある
それらは購入されているか、社内で構築されているか、あるいはその両方の組み合わせである
これに加えて、今も生き残っているレガシーシステムもある
今日では、企業がいくつかのデータウェアハウス、数十のウェブサイト、ERPシステムの複数のインスタンス、および多くの他の部門アプリケーションを持っていることが一般的である
すべてのビジネス・プロセスを実行する単一のアプリケーションを構築することはほとんど不可能である
より大きなオールインワンソリューションの技術的な境界に縛られるのではなく、必要なペースで動くための十分な柔軟性と機敏性をビジネスに提供する必要がある
これは、最適な顧客関係管理 (CRM) システムと、最適な注文管理システム (OMS) および最適なエンタープライズリソースプランニング (ERP) ソリューションを組み合わせることを意味する

一方、ユーザーは、これらの境界や背後にあるシステムについてはあまり気にしない
彼らは、ビジネス機能が、それを提供するシステムやシステムに関係なく実行されることを期待している
たとえば、顧客がオンラインで注文を行う場合、顧客の履歴またはクレジットスコアの確認、在庫の確認、税金の計算、注文の作成、注文の処理、出荷の処理、請求書の送信、支払いの回収など、複数の機能を提供するために、
複数のシステム間で調整が必要になる可能性がある
これらのプロセスは複数のシステムにまたがることができるが、お客様の観点からは、これは単一のトランザクションであり、多くのお客様の期待に応える
このような分散機能をサポートするためには、これらのアプリケーションを効率的、安全、スケーラブル、および信頼性の高い方法で統合する必要がある

一般的なエンタープライズ統合のニーズ

適切な情報を取得する
情報を適切な場所に格納する
適切なタイミングで情報を取得する
変化の柔軟性と受け入れ
ビジネス・プロセスの調整

統合アーキテクチャ設計原則

ネイティブ統合
他のアプリケーションとのコラボレーションを必要とせずに、すべてのビジネスニーズを単独で満たすことができる単一のスタンドアロンアプリケーションを開発できれば、統合要件によって引き起こされる多くの複雑さを回避できる
しかし、これは新しいビジネス要件を満たすための調整が困難な複雑なシステムを作成することになるため現実的ではない
Salesforce製品の多くはネイティブに統合されており、その多くは市場で最高の製品と考えられており、さまざまなユーザーエクスペリエンスを提供する機能を備えている
たとえば、Salesforce Communitiesは、CRMとネイティブに統合された顧客ポータルを公開するためのネイティブソリューションを提供する
何らかのテクノロジを使ってカスタムメイドの顧客ポータルを構築し、それを安全でコンプライアンスに準拠した方法でSalesforceと統合する方法を見つける必要があるソリューションよりも、それを支持するのは理にかなっている
さらに、ネイティブ統合を使用すると、将来的に他のネイティブ統合機能を使用できるようになる
シンプルさ
できるだけ複雑な解決策は避け、常に黄金の80-20のカスタマイズルールを念頭に置く
過度に複雑なアーキテクチャを使用してユースケースの100%をカバーするソリューションをターゲットにするよりも、単純化されたアーキテクチャを使用してユースケースの80%を満たす方が望ましい
疎結合の統合では、統合インターフェイスは特定の機能を提供するのに十分な固有性を持つが、必要に応じて変更できるだけの汎用性を持つ
タイミング
統合アーキテクチャは、アプリケーションがデータを送信してから別のアプリケーションがそれを受信するまでの時間を最小限に抑えるようにする必要がある
統合アーキテクチャは、できるだけ頻繁に小さなデータチャンクを共有することを目的とする必要がある
アーキテクチャを設計する際には、データ共有の遅延を考慮する必要がある
データ交換プロセスに時間がかかるほど、より複雑になり、データの状態の変化などの他の課題が発生しやすくなる
バルクデータ交換は、運用データのアーカイブなどの適切なユースケースにも使用できる
同期と非同期
同期プロセスでは、プロシージャはすべてのサブプロシージャの実行が終了するまで待機する
ただし、統合環境では、統合されたアプリケーションが異なるネットワーク上にある場合や、必ずしも同時に使用できるとは限らない場合があるため、プロシージャがすべてのサブプロシージャの終了を待機する必要がないユースケースが増えることがある
これは単にサブプロシージャーを呼び出してから、それをバックグラウンドで非同期に実行させ、今日の多くのアプリケーションで利用可能なマルチスレッド機能を利用する
統合テクノロジー
適切なテクノロジーの選択が不可欠である
データ形式
統合プロセスには、データをある形式から別の形式に変換する中間ステップが必要である
データ形式の変更や拡張に対応する柔軟性は、統合アーキテクチャの柔軟性を定義する上で大きな役割を果たす
データと機能
Salesforceアーキテクトとして、特定の統合パターンを認識し、プラットフォームの制限を理解する必要がある

一般的な統合スタイルの紹介

2つ以上のシステム間の統合アーキテクチャを設計する場合、重要な課題は、それを実際に実現する方法である

ファイル転送

この統合スタイルでは、アプリケーションは他のアプリケーションが使用するデータを含むファイルを生成する
このファイルは、通常、すべてのターゲットシステムで読み取り可能な形式であり、関係するすべてのシステムからアクセス可能なリポジトリに共有される
これらのシステムは、想定している他の形式にファイルを変換し、ファイルのプロデューサーは、ビジネスニーズに基づいて定期的にデータファイルを生成する
この方法の課題の1つは、生成されるファイルの種類である
一部のレガシーアプリケーションでは、XMLなどの標準形式でデータを生成できない場合がある
このアプローチのタイミングとスケーラビリティの限界も問題となる
この方法は、特定の時点でデータのスナップショットを交換する場合にのみ適している
レガシーシステムまたはApiをサポートしていない外部システムからレポートデータをレプリケートする必要があり、他のメカニズムを使用してそのデータへのアクセスを許可しない場合に有効である

統合データストア

1つのアプリケーションがデータを更新した場合、他のシステムは、データを取得しようとするとすぐに、最新の更新バージョンのデータにアクセスできる
関連するすべてのシステムは、指定された基本構造で動作するように構築されているため、データ変換を行う必要はない
このアプローチの課題は、アプリケーション間、およびアプリケーションとデータベース間の高い依存性である
すべてのシステムが統合されたデータベースで動作することを期待するのは現実的ではない
このアプローチは、分散システムの初期、特にクライアント/サーバー・アーキテクチャでは非常に一般的だった
現実的には、このアプローチには多くの課題がある
今日のエンタープライズアプリケーションは、独自のデータベースで動作するように設計および構築されているという事実がある
変更には多くの時間と費用が掛かり、元のアプリケーションの主要な機能が失われたり、パフォーマンスのボトルネックが発生したりする可能性がある

リモートプロシージャ呼び出し

たとえば、アプリケーションAの注文状態の変更によって、アプリケーションBの法人の作成がトリガーされる場合がある
このプロセスを簡略化し、アプリケーションの依存関係を減らすために、リモートプロシージャ呼び出し (RPI) が導入された
歴史的には、CORBAやなど、RPIの概念を実装した技術がいくつかあった
今日の世界で最も好まれているテクノロジはWebサービスでありSOAPとRESTという2つの一般的な標準仕様がある

メッセージング

メッセージングは非同期スタイルの統合であり、複数のシステムがメッセージバスを介して緩やかに統合される
メッセージバスには、送信者を受信者 (チャネルと呼ばれる) に接続する複数の仮想パイプと、メッセージルーターが含まれる
メッセージルーターは、チャネルのトポロジをナビゲートしてメッセージを適切な受信者に配信する方法を決定するコンポーネントである
このスタイルでは、統合システムは必ずしも同時に稼働している必要はなく、この非同期性は要求の厳しいアプリケーションをサポートするための拡張性が高い
この統合スタイルは、今日の企業で広く採用されているエンタープライズサービスバス (ESB) の原則を提供している

さまざまな統合ツールの検討

今日利用可能な一般的な統合ツールについて説明する前に、なぜこれらのツールが必要なのかを説明する必要がある
Salesforceアーキテクトは、合意された統合戦略をサポートする適切なツールセットを選択する際に、クライアントと統合チームを指導する必要がある
そして、妥当な論理と合理性に基づいて、次善の設計決定に挑戦できる必要がある
レビューボードでは、統合ツールを選択した理由を常に説明する必要がある
従来、2つのアプリケーションを統合する一般的な方法は、サードパーティ製のアプリや仲介者を介さずに直接チャネルを使用するこおである
これは、ポイント・ツー・ポイント統合 (P2P) という方法である

ポイント・ツー・ポイント統合

独自のチャネル確立
相互に対話する必要があるアプリケーションの各ペア間に一意のチャネルが確立される
N台のシステムを接続するために必要な固有チャネルの数は、N (N-1) /2の式を使用して計算できる
たとえば、一方向のインターフェイスを介して3つのシステムを接続する必要がある場合は、3つの一意のチャネルが必要になる
10個の異なるアプリケーションをリンクするには、10* (10-1) /2=45個の一意のチャネルが必要である
これらのチャネルのそれぞれは、定期的に開発、文書化、テスト、保守されなければならなない
実際のコストは、ランドスケープにシステムを追加したり、追加のシステムをランドスケープに接続したりするコストが線形ではないため、マクロ・レベルで示され始める
前述の状況にさらに3つのアプリケーションを追加するにはコストは予測不可能であり、新しいアプリケーションの性質とそのビジネス機能によっては、コストが大幅に増加する可能性がある

ハブアンドスポーク方式は、はるかに少ないチャネルしか必要としない

この方法では、各アプリケーションはスポークであり、特定のトランザクションのハブにのみ接続される
これにより、追加のシステムをフックするために必要な新しいチャネルの数を簡単に予測できるため、状況がはるかに柔軟になる
次の図は、両方のアプローチに必要なチャネル数を比較したものである

P2P接続とハブアンドスポーク接続の両方における一意のチャネルの数

プロセスのオーケストレーション
プロセスオーケストレーションは、チャネルレベルでも処理する必要がある
これには、例外処理と再試行メカニズムが含まれる
たとえば、オンラインWebページから顧客と注文情報を収集する注文取り込みアプリケーションAがあるとする
次に、それを注文管理アプリケーションBに渡す
このアプリケーションは、顧客データと注文データを別々に格納する
両方のアプリケーションに、他のアプリケーションから呼び出すことができるセキュアなAPIがあると仮定する
この場合、アプリケーションAはアプリケーションBの顧客作成APIを呼び出し、プロセスが正常に完了したという応答を受け取ると、注文作成APIを呼び出して、最近作成された顧客に関連する注文を作成する
統合チャネルは、アプリケーションBの使用不可など、何らかの理由で顧客作成の潜在的な障害を処理するように構築する必要がある
包括的な例外処理とログ機能を備えた再試行メカニズムを実装する必要があり、通知メカニズムやロールバック機能も持っているとより望ましい
これらはすべて、ランドスケープ内のすべてのP2P統合チャネルで繰り返す必要がある
これには多大な労力が必要であり、統合ソリューションの全体的な信頼性が低下することは避けられない
総合信頼性
統合ソリューションの全体的な信頼性は、特にP2P接続を使用する場合に考慮すべき重要なトピックである
A、B、およびCの3つの異なるアプリケーションの統合ソリューションを想像してみる
特定のビジネスプロセスの場合、アプリケーションAはアプリケーションBと通信する必要があり、アプリケーションBはアプリケーションCと通信する
P2P接続を使用する場合、これは3つのシステムが連続して接続されていると考えることができる
つまり、統合ソリューション全体の信頼性は、R=A 1-RA 2-RA 3-R*...*AN-Rという式を使用して計算できる

ここで、AN−Rは、アプリケーションAの信頼性である
この例では、アプリケーションに次の信頼性があると仮定する
A 1-R=0.9
A 2-R=0.8
A 3-R=0.5
ここで、全体の解は、0.9×0.8×0.5=0.36の信頼性を有する
P2Pの代わりにハブアンドスポーク方式を使用すると、接続が簡素化されるため、ソリューション全体の信頼性が大幅に向上する
ハブ自体はボトルネックになる可能性があるが、問題になる可能性のあるものは少なくなる

P2P接続の課題

限られた機能
すべてのデータ変換とプロセスオーケストレーションが個々のチャネルで行われるため、これらのチャネルの多くは単純でわかりやすい統合になる
また、シンプルさはアーキテクチャ上の目標であり、目標とすべきものだが、P2Pによって課される技術的な能力が限られているため、複雑なビジネス差別化サービスを導入するビジネスの能力が事実上制限される
変更のボトルネックになる
時間の経過とともに、P2P統合の維持とサポートは必然的に困難になる
変更や新しい機能追加、ホットフィックスを展開するプロセスは、ますます遅くなり、コストがかかる
高い依存関係
通常、密結合された統合アプリケーションは、相互に高い依存性を持つ
P2Pベースのランドスケープでは依存性が高いため、ランドスケープ内の他のすべてのアプリケーションに直接影響を与える可能性がある
拡張性
上記の理由により、P2Pがスケーラブルなエンタープライズソリューションを設計するための適切なオプションではない理由は容易に理解できる

統合アーキテクチャを提案する際は、このセクションで説明したすべての考慮事項を念頭に置いておく必要がある
レビューボードでは、最高の技術的ソリューションを考え出すことが求められる
そして、実業務では、利害関係者に長所と短所を明確に伝え、彼らが持っているさまざまなオプションを説明できる必要がある
これは、利害関係者が最適なものを選択するのに役立つ

データの抽出、変換、ロード (ETL)

この統合方法は、ファイル転送統合スタイルのいくつかの原則に従っており、最新のETLツールでは、メッセージングスタイルから継承された原則の一部も使用している

データ抽出では、1つ以上のデータソースにアクセスし、そこからデータを抽出する
データ変換には、データクレンジング、データ書式設定、データエンリッチメント、データ検証、データ拡張など、最終的な送信先に配信される前にデータに対して行われるすべてのアクティビティが含まれる
データ・ロードには、データにアクセスして最終的なターゲット・データ・ストアにロードするために必要なプロセスが含まれる
ETLツールでは、データをステージング領域またはステージングデータストアにステージングして、重複除外、カスタムロジック、外部参照データの検索によるデータエンリッチメントなどの複雑な変換を行うことができる
3つのETLプロセスには時間がかかるため、一般的には、これらのプロセスを非同期方式でスケジュールまたは実行する
最新のETLツールのほとんどは、数分ごとに特定のジョブを実行するようにスケジュールでき、一部のETLツールでは、トリガー可能なエンドポイントを公開することもできる
これは、1つ以上のETLジョブをトリガーするために、特定の承認された送信者からメッセージを受信できるHTTPリスナーである
たとえば、リスナーを公開して、特定のSalesforceインスタンスから特定の種類の送信メッセージを受信できる
送信メッセージを受信すると、リスナーは1つ以上のETLジョブをトリガーして、Salesforceや他のシステムでデータを取得または更新する
現在のETLツールのほとんどには、Salesforce、Microsoft Azure、Amazon Redshift、Amazon S 3、SAPなど、さまざまな種類のアプリケーションデータベース用の組み込みコネクタが付属している
さらに、Open Database Connectivity (ODBC) やJava Database Connectivity (JDBC) などの汎用データベースAPIへのアダプターも付属している
ファイル転送プロトコル (FTP) とSSHファイル転送プロトコル (SFTP) 用のコネクタを提供するものもある
これらのコネクタを使用すると、最適化された方法で特定のアプリケーションデータベースにアクセスできる
たとえば、Salesforceコネクタは、実行された操作と処理されるデータの量に応じて、Salesforceの標準REST API、Salesforce SOAP API、またはSalesforce BULK APIを使用して自動的に切り替えるように構築できる

企業でホストされているアプリケーションとデータベースは、通常、企業のファイアウォールの内側に存在する
セキュリティチームは、クライアントがクラウドベースのETLツールとやり取りできるようにファイアウォールを構成する必要がある

ETLツールは、データ・レプリケーション操作に非常に適している
数百万~数十億のレコードを処理できるため、堅牢で拡張性の高いサービスを提供するように設計および構築されている
ETLツールは、メディア・ファイルのレプリケートなど、時間がかかるデータ・レプリケーションにも最適である
現在、Salesforceで使用されているETLツールの中で最も人気が高いのは、Informatica PowerCenter、Informatica Cloud、Talend、Jitterbit、MuleSoftなどである
MuleSoftは通常ESBツールと考えられているが、実際には両方の統合方法をサポートしている

エンタープライズ・サービス・バス

エンタープライズサービスバス (ESB) は、さまざまなアプリケーションが通信バスを介して統合されるデータ統合の特定の方法に付けられた名前である
各アプリケーションは、バスのみと通信するため、アプリケーションが分離され、依存関係が減少する
これにより、システムは他のシステムがどのように動作しているかの詳細を知らなくても通信できる
この統合メソッドは、メッセージング統合スタイルとリモート・プロシージャ呼び出しスタイルの原則に従う
ESBツールはこの概念をさらに発展させ、現在、マイクロサービス、API主導の接続、イベント駆動アーキテクチャなどのさまざまなアーキテクチャ概念をサポートしている

ESBは、同期型と非同期型の両方の通信をサポートしているため、RPIが重要な機能であるビジネスロジック層で動作する統合に最適である
通常、ESBはステートレスであるため、バス内の各メッセージの状態はメッセージ自体の一部として含まれる
データがバスを通過している間は、正規のデータ形式であると見なされる
標準的なデータ形式は、ランドスケープ内の同じデータの他のすべてのモデルを設定するデータのモデルである
この標準データは、通常、ターゲットデータモデルに変換される
クラウド情報モデル (CIM) は、標準データモデルの好例である

ESBは複雑なオーケストレーションを処理できる
たとえば、アプリケーションAが顧客の詳細をESBに送信し、ESBが複数の外部アプリケーションと通信してリアルタイムの信用調査を実行した後、CRMシステムを呼び出して顧客のオンボーディングを開始する場合がある
顧客オンボーディングエクスペリエンスは、成功メッセージと共にアプリケーションAに返される一意の顧客IDを生成する
ESBは複雑なオーケストレーションを処理することができ、サポートデータベースを一時ストレージまたは一部のデータのキャッシュとして使用できる
通常、データベースは同じサーバー上のESBツールと共存し、最短の応答時間を提供する

ESBは、必要なあらゆる種類のデータクレンジング、データの書式設定、データのエンリッチメント、データの検証、データの拡張、およびさまざまなデータ形式との間の変換も処理する
たとえば、アプリケーションAがIntermediate Document (IDoc) 形式のデータをESBに送信し、ESBがそれを受信して、ルックアップ/参照データソースからの他のデータでデータを拡張し、それをXML、CSV、JSONなどの受信者が期待する形式に変換する
ESBは、同じコンポーネントに対して複数のインタフェースを提供することもできる
これは特にWebサービスの下位互換性を提供する場合の利点である
ESBは通常、非常にスケーラブルで、非常に高い負荷のトラフィックを処理できるように設計されている
いくつかの最新のESBは、ローカルでホストするオプションを備えたSaaS形式で提供されているものもある
ステートレスであるため、ESBは、システム間で大量のデータをレプリケートしたり、大きなメディアファイルを移動したりするような、長時間実行される操作には適していない

Salesforceアーキテクトとして、現在使用されている一般的なESBのいくつかを知る必要がある
また、環境の一部としてESBを利用することを提案するタイミングと理由を理解する必要がある
ESBとETLの違いを完全に理解し、どちらが何に適しているかを十分に理解しておくことが重要である
ほとんどの場合、企業がP2P接続ではなく何らかのミドルウェアを使用する必要がある理由を理解しておく必要がある
また、特定の実装で最適な方法で使用されているかどうかを認識するために、ESBの理想的なユースケースを理解しておくこと
Salesforceで現在使用されているESBツールには、MuleSoft webMethods Integration ServerやIBM Integration Bus、TIBCO ActiveMatrix Service Bus、WSO 2 Enterprise Integratorなどがある

リバースプロキシ

リバースプロキシは、サーバー (またはサーバー) が自身と潜在的なクライアントの間に配置する
エンドクライアントの場合、この場合に取得されたリソースは、その背後にあるサーバーではなく、プロキシサーバー自体によって生成されたものとして表示される
リバースプロキシは、多くの場合、信頼されていないクライアント (承認されていないインターネットユーザーなど) を処理するためのより安全なインターフェイスを提供するために使用される
また、過剰な負荷を処理する機能がないか、必要な適切なセキュリティ対策を提供できない可能性がある他のアプリケーション (HTTPSをサポートできないなど) をシールドするためにも使用される
リバースプロキシは、HTTPS要求のHTTPへの変換、Cookieとセッションデータの処理、1つの要求のバックグラウンドでの複数の要求への変換、応答の結合、受信要求のバッファリングなどの機能を提供して、シールドされたサーバーを過剰な負荷から保護する
リバースプロキシ製品のプロバイダには、VMware、Citrix Systems、F5Networksなどがある

APIゲートウェイ

APIゲートウェイは、従来、内部Webサービス (またはAPI) を保護するために使用される
企業の内部APIは、認証やスケーラビリティなどのトピックを処理するように設計されていない可能性があるため、APIゲートウェイは、APIを保護するだけでなく、APIの収益化、リアルタイム分析の提供、サービス拒否 (DoS) 攻撃からの保護など、他の一連の機能を有効にするためのレイヤーを提供する
APIゲートウェイは、リバースプロセスの概念とよく似ている
実際には、APIゲートウェイは特殊な種類のリバースプロキシと考えることができる
場合によっては、APIゲートウェイが負荷分散を処理するリバースプロキシの背後に配置されている状況で、両方を使用できる
APIゲートウェイは通常、APIまたはUIを使用して構成できる
一方、リバースプロキシは通常、構成ファイルを使用して構成され、新しい構成セットを使用できるように再起動する必要がある
APIゲートウェイは、レート制限、クォータ、サービス検出などの高度なAPI機能も提供する
Salesforceアーキテクトとして、現在使用されている一般的なAPIゲートウェイについて理解する必要がある
現在Salesforceで使われているものとして、MuleSoftやMicrosoftのAzure API Management、Google (Apigee) 、IBM API Managementなどがある

ストリーム処理プラットフォーム

ストリーム処理プラットフォームは、並列処理を最大限に活用するように設計されたシステムである
これにより、サーバーの計算機能を活用できる
このプロセスは、メッセージング統合スタイルからいくつかの原則を継承している
ストリーム処理プラットフォームはメッセージキュープラットフォームと呼ばれることがよくある
ストリーム処理プラットフォームは大量の受信データを処理できる
また、通常はコンテナーに簡単にカプセル化できるため、クラウド、オンプレミス、ハイブリッド環境などのさまざまなプラットフォームに簡単にデプロイできる
ストリーム処理プラットフォームは、その機能と性質から、IoTサーバーなどの非常にスケーラブルなメッセージングプラットフォームが必要なユースケースに最適である
現在使用されている最も一般的なストリーム処理ツールには、Apache Kafka、Amazon Kinesis、Redis、RabbitQなどがある
Salesforce Herokuは、Kafkaなど、これらのテクノロジの一部をサポートしている

暗号化–一般的な概念を理解する

暗号化は、統合やIDおよびアクセス管理 (IAM) など、他のいくつかのアーキテクチャドメインと密接な関係がある
また、データとの密接な関係もある
Salesforceアーキテクトとして、暗号化の価値、さまざまな種類の暗号化アルゴリズム、およびそれらの動作方法についての高度な理解が必要である

キー/暗号化キー
暗号化キーは、暗号化アルゴリズムの出力を制御する入力パラメータである
前に説明したように、キーは暗号化プロセスの重要な要素である
キーは、暗号テキストを解読するためにも必要である
それがないと、暗号文は役にたたないと考えられる
攻撃者は、情報を暗号化するために使用されたアルゴリズムを把握できるが、キーが秘密にされている限り、それは問題にならないはずである
長い暗号化鍵を生成するプロセスは非常に複雑である
対称暗号化アルゴリズムでは、通常、長さが128ビットと256ビットのキーが使用される
一方、非対称暗号化アルゴリズムでは、通常、1,024ビット長と4,096ビット長のキーが使用される
キー管理
これは、暗号化キーを管理するプロセスである
キーの生成、交換、格納、使用、置換、および破棄が含まれる
キーと証明書は通常、リポジトリで管理される
最近、クラウドプロバイダーは、bring your own encryption (BYOE) またはbring your own key (BYOK) と呼ばれるメカニズムをサポートし始めた
これは、クラウドプロバイダーによって提供またはホストされるキーリポジトリに依存するのではなく、暗号化キーを完全に制御できるようにすることで、クライアントがクラウドにデータを格納する際の信頼性を高めることを目的としている
Salesforce ShieldはBYOKのコンセプトをサポートしている
初期化ベクトル
通常、これは暗号化プロセス中に使用される初期値と考えることができる
反復処理の開始時に使用される可能性がある
この擬似乱数値は、各メッセージが別々に暗号化されることを保証するために使用される
同じメッセージが2回暗号化された場合でも、結果は毎回異なるものになる
これは、暗号文の2つのブロックが実際には同じ平文に基づいていることに攻撃者が気付かないため、暗号文のセキュリティを強化するのに役立つ
多くのアルゴリズムは初期化ベクトルを暗号文の最初の128ビットに設定する
メッセージが悪意のある人の手に渡った場合、攻撃者は初期化ベクトルを簡単に取り出すことができるが、キーがなければ役に立たない
キーを持つ受信者は、キーと一意の初期化ベクトルを使用してメッセージを復号化する

Salesforce Cryptoクラスには、encryptWithManagedIVメソッドとdecryptWithManagedIVメソッドがある
これらのメソッドは、標準のencryptメソッドとdecryptメソッドとは異なり、入力パラメーターとして初期化ベクトルを想定していない
encryptWithManagedIVとdecryptWithManagedIVはどちらも暗号化されたメッセージから初期化ベクトルを抽出し、暗号文の先頭にあると想定する

salt
saltは、入力に追加される擬似乱数データである
saltは主に一方向ハッシュアルゴリズムで使用される
たとえば、ユーザーパスワードをキャプチャするシステムは、結合されたテキストをハッシュする前にsalt値を追加できる
これにより、攻撃者が元のパスワードの長さを推測するのが困難になる
さらに、salt値が毎回ランダムであることを考慮すると、2つの類似した入力の場合、出力はまったく異なる
パスワードの例に戻ると、攻撃者がパスワードの1つを解読できたとしても、同じパスワードを使用してアカウントを侵害した他のユーザーがいるかどうかを推測する方法はない
証明書
証明書は、公開キーと呼ばれる暗号化キーに加えて、発行者、証明書の目的、その他のデータなどの情報を含む電子ドキュメントである
証明書は、証明書の公開キーの秘密キーを所有する特定のエンティティ (Webサーバーなど) の信頼性を証明するために使用される
公開キーと秘密キーは、非対称暗号アルゴリズムで使用される用語である
証明書自体は、発行者によってデジタル署名できる
パブリックwebサイトの場合、ここでの発行者は、証明機関 (CA) と呼ばれる3番目の独立したエンティティになる
CAの例としては、Comodo、GeoTrust、Symantecなどがある
証明書の簡単な例
セキュアHTTPS Webサイトにアクセスすると、そのWebサイトの証明書がブラウザに表示される
証明書にはサーバーの公開鍵が含まれている
これはCAによって発行されるため、証明書自体には、証明書の信頼性を確認するCAのデジタル署名が含まれる
ブラウザは、公開鍵とCA署名を使用して、通信相手のサーバが本当に正しいサーバであることを確認するとともに、そのサーバとの通信が中間者攻撃から保護されることを保証できる
CA機関によって発行または署名された証明書は、通常、CA署名証明書と呼ばれる
ブロック暗号 (Block cipher)
固定長のビット群 (ブロックと呼ばれる) を扱う暗号アルゴリズムの名称
たとえば、Advanced Encryption System (AES) アルゴリズムは、128,192ビットや256ビットなどの異なる長さのキーを使用して128ビットブロックを暗号化する

暗号化アルゴリズムのタイプとユースケース

暗号化アルゴリズムには、対称暗号化アルゴリズムと非対称暗号化アルゴリズムの2種類がある

対称暗号アルゴリズム

これは、プレーンテキストの暗号化と暗号化テキストの復号化の両方で対称キーに依存するアルゴリズムのファミリである
この種のアルゴリズムでは、安全で安全な方法でキーを格納することが非常に重要である
攻撃者が使用されているチャネルを傍受してキーにアクセスできる可能性があるため、送信者と受信者の間でキーを共有する必要がある
対称暗号アルゴリズムには、相互暗号または自己相互暗号とも見なされるアルゴリズムがいくつかある
これは、プレーンテキストを取得し、特定のアルゴリズムロジックを通過させて、暗号化キーを使用して暗号テキストに変換できる暗号アルゴリズムの一種である
そして暗号文を受け取って、同じ鍵を使ってまったく同じロジックを通過させ、再び平文を生成する
この例としては、有名な第二次世界大戦のEnigmaマシンに加えて、XOR暗号やBeaufort暗号がある

対称暗号アルゴリズムには、主にストリーム暗号とブロック暗号の2種類がある
一般的な最新の対称暗号化アルゴリズムの例としては、データ暗号化標準 (DES) 、Blowfish、およびAESとその異なるバージョンがある
AES 128、AES 192、ES 256のAESは、Salesforce Cryptoクラスでサポートされている

ハッシュアルゴリズム

ハッシュアルゴリズムは、プレーンテキストからダイジェストを作成する
ダイジェスト (ハッシュ値とも呼ばれる) をプレーンテキストに戻すことはできない
ハッシュアルゴリズムは一方向関数であり、出力を反転できない単純な関数である
ハッシュ・アルゴリズムには、次のプロパティがある
決定論的には、同じメッセージに対して常に同じ結果が得られる
その性質上、攻撃者が特定のハッシュを生成するメッセージを生成しようとすることは不可能である
通常、ハッシュアルゴリズムはキーを必要としない
ハッシュアルゴリズムの目的は、元の平文の整合性を確保することであることに注意しておく
ハッシュアルゴリズムはコンピュータシステムで広く使用されている
デジタル署名やMACアルゴリズムで使用されるほか、暗号キーの生成、インデックスデータの作成、重複データの検出、メッセージチェックサムの作成にも使用される

一般的な最新のハッシュアルゴリズムの例としては、Message-Digest Algorithm (MD 5) 、Whirlpool、およびSecure Hash Algorithm (SHA) とそのさまざまなバージョンがある
SHA-1、SHA-256、およびSHA-512のSHAは、Salesforce Cryptoクラスでサポートされている

次の図は、ハッシュアルゴリズムの一般的なメカニズムを示している

ハッシュアルゴリズムのしくみの図

MACアルゴリズム

MACアルゴリズムは、平文の一方向ダイジェスト/ハッシュを生成するという意味でハッシュアルゴリズムに似ている
しかし、MACアルゴリズムは主に、メッセージ自体が改ざんされていないことを検証することに加えて、メッセージ送信者の信頼性を検証するために作成される
そのために、MACアルゴリズムはプロセスでキーを使用する
通常、これはハッシュ値自体を暗号化するために使用される
キーは、送信者と受信者の両方に認識されている必要がある
これは、ハッシュを生成したエンティティが同じキーのコピーを所有していることを確認するために使用できる
一般的な最新のMACアルゴリズムの例としては、keyed-hash message authentication code (HMAC) とその様々なバージョンがある
hmacMD 5、hmacSHA 1、hmacSHA 256、およびhmacSHA 512は、Salesforce Cryptoクラスでサポートされている

次の図は、MACアルゴリズムの一般的なメカニズムを示している

MACアルゴリズムの動作の説明

非対称暗号化アルゴリズム

公開キー暗号化アルゴリズムとも呼ばれ、通信する2つのエンティティが異なるキーのペアを使用できる暗号化メカニズムを作成するように設計されている
1つは秘密鍵と呼ばれ、秘密にしておく必要がある
もう1つは公開鍵と呼ばれ、配布しても安全である
このようなアルゴリズムでは、アプリケーションは公開鍵を使用してメッセージを暗号化でき、このメッセージはペアになった秘密鍵を使用してのみ復号化できる
1つの鍵で施錠でき、別の鍵で開けることができる鍵のついたバッグを持っているようなものである
非対称暗号化アルゴリズムのキーペアの生成プロセスは、対称キーの生成に使用されるプロセスよりもはるかに複雑である
さらに、非対称アルゴリズムは通常、実行が複雑で時間がかかる
非対称暗号化アルゴリズムには多くの用途があるが、主に次の2つのユースケースで使用される

メッセージの機密性
前述したように、公開鍵を配布しても安全である
秘密キーは、暗号メッセージを受信して復号化するエンティティと共に秘密にしておく必要がある
この場合、非対称アルゴリズムは、キーの分散という対称アルゴリズムで経験する主な課題の1つを解決する
非対称アルゴリズムを使用すると、メッセージは公開キーで暗号化され、両方のキーペアを最初に発行したエンティティによってのみ秘密キーを使用して復号化できる
このメカニズムでは、秘密キーの所有者が受信メッセージの機密性を確保できる
よく知られた非対称暗号アルゴリズムには、ElGamal、RSA、Diffie-Hellman鍵交換などがある
デジタル署名
この場合、秘密鍵は、メッセージのダイジェスト/ハッシュ値を生成することによって、特定のメッセージに効果的に署名するために使用される
公開キーにアクセスできるすべてのユーザーが署名を検証できる
検証プロセスは、メッセージに署名したエンティティが秘密キーにアクセスできることを証明し、送信者の信頼性を証明する
公開キーを使用してデジタル署名を検証していることを覚えておく必要がある
公開鍵の配布が問題になることはない
デジタル署名に使用される一般的な非対称暗号化アルゴリズムの例としては、RSA-SHA 1、RSA-SHA 256、RSA-SHA 384、RSA-SHA 512などがある
これらはすべて、SalesforceのCryptoクラスでサポートされている

暗号化のユースケース

TLSがどのように機能するかの詳細を理解する

TLSの仕組みを理解する

Transport Layer Security (TLS) は、Secure Sockets Layer (SSL) に代わる暗号プロトコルである
ネットワーク (インターネットなど) を介した2つのコンピューターアプリケーション間の通信をセキュリティで保護するように設計されている
TLSにはこれまで4つのバージョンがある(1.0、1.1、1.2、および1.3)
Salesforceは、最新かつ最も安全なTLSバージョンをサポートするよう、プラットフォームのアップデートを続けている
可能な限り最新バージョンのTLSを使用すること
通信チャネルがTLSによって保護されている場合、2者間の通信には次のプロパティが1つ以上ある

プライベート接続
対称暗号化アルゴリズムを使用して、送信データを暗号化する
この暗号化に使用されるキーは、セッションごとに一意であり、ハンドシェイクプロセスの一部として生成される
ハンドシェイクプロセス自体も、中間者攻撃に対しても安全である
Authentic identity
CA署名付き証明書を使用する非対称暗号化プロセスを使用して、通信する2つのパーティのIDを検証できる
通信相手の身元を確認することは任意だが、通常は少なくともサーバでは必要である
たとえば、クライアントがHTTPS webサイトを開こうとした場合–両方のパーティのidが検証されると、これは双方向のTLSセキュリティで保護されたチャネルになる
信頼性
交換される各メッセージには、メッセージ自体が変更または改ざんされていないことを確認するためのMAC値も含まれる

次に、ユーザーがhttps://www.salesforce.com:などのセキュリティで保護されたWebサイトに移動しようとするとどうなるかについて、大まかな詳細を見ていく

1.クライアント(この場合のブラウザ)はハンドシェーク処理を開始する
クライアントは、サポートする暗号スイート (およびそのバージョン) のリストを提供する
2.サーバー (この場合はhttps://www.salesforce.com,) は、クライアントによって提供される暗号化方式群のいずれかをサポートして使用する意思があるかどうかを確認する
TLS 1.1より前のバージョンを使用するようにブラウザーが構成されている場合、接続は拒否される
サーバーは、クライアントがサポートする暗号化方式群の1つを使用することに同意すると、CA署名付き証明書を含む応答を返す(証明書には公開鍵も含まれる)
3.クライアントは、指定された証明書を前述のCA機関で検証する (デジタル署名の検証)
この手順は、通信しているWebサイトが本物であり、実際に主張している内容であることをクライアントに保証するために必要である
証明書が正常に検証されると、クライアントは証明書から公開キーを抽出する
4.クライアントはランダムなpre-masterキーを生成し、公開キーで暗号化する
つまり、この事前マスター鍵は、秘密鍵の所有者によってのみ復号化できる
クライアントは、この暗号化されたプレマスターキーをサーバーに送信する
5.サーバーは、その秘密鍵を使用してpre-masterキーを復号化する
6.クライアントとサーバーの両方が、共有シークレットまたはセッションキーと呼ばれる新しい共有キーを計算するために、事前マスターキーを使用する
ステップ4、ステップ5、およびステップ6は、Diffie-Hellmanキー交換を使用して実行することもできるが、これは本書の範囲外である
7.クライアントは、セッションキーを使用して暗号化された新しいテストメッセージを送信する
これは、単純な対称暗号化である
8.サーバーはセッション・キーを使用してメッセージを復号化し、処理が成功したことを確認する
これは、会話全体をリッスンしているサードパーティの攻撃者が存在する場合でも、セキュリティで保護され、自分だけが知っている一意の非対称暗号化キーを、両者が正常に交換できたことを意味する
セッションキーは安全で、クライアントとサーバーのみが認識する
9.これ以降、2者間の通信は、セッションの残りの部分でセッションキーを使用して行われる
また、すべての交換メッセージは、セッションキーを使用するMACで保護される

双方向TLSのしくみ

Two-way TLS (今でもTwo-way-SSLと呼ばれることもある) は、標準的な一方向TLSに非常によく似ているが、大きな違いが1つある
一方向TLSでは、クライアントはサーバーのIDを確認するためにサーバーの証明書を検証する
クライアントは、ID検証が成功するとサーバーのIDを確信できるが、サーバーはクライアントのIDを確認する方法がない
これまでの例では、パブリックサーバーは毎分数千または数百万のユーザーによってアクセスされるため、これはおそらく重要ではない
彼らは身元を確認することなく、彼ら全員にサービスを提供している
しかし、サーバーが、限られたクライアントだけが利用できるサービスを提供している場合はどうか？
これは、まさに双方向TLSが使用される場所であり、これが相互認証または双方向認証と呼ばれることがある理由である

双方向TLSのフロー

1.クライアント(この場合、通常はブラウザーではなくアプリケーション)はハンドシェーク処理を開始する
クライアントは、サポートする暗号スイート (およびそのバージョン) のリストを提供する
2.一方向TLSの説明のステップ2と同様
3.一方向TLSの説明のステップ3と同様
4.クライアントはランダムなpre-masterキーを生成し、公開キーで暗号化する
つまり、この事前マスター鍵は、秘密鍵の所有者によってのみ復号化できる
クライアントは、この暗号化されたプレマスターキーと共に、独自の証明書をサーバーに送信する
5.サーバーは、クライアントの証明書を前述のCA権限で検証する (デジタル署名の検証)
また、特定のクライアントのみにアクセスを制限するようにサーバーを構成することもできる
この場合、サーバーは、指定された証明書を、保持している許可されたクライアント証明書のリポジトリと比較する
指定された証明書が含まれている場合は、次の手順に進む
6.残りの手順は、一方向のTLSと同様
双方向TLSは、多くの運用環境(Salesforceの世界では、これらは本番インスタンスと呼ばれている)が同じインフラストラクチャ、ドメイン名、およびIP範囲を共有するという事実から、特にSaaSの世界で非常に一般的なメカニズムである
双方向TLSは、適切なクライアントアプリケーションのセットによって適切なインスタンスにアクセスできるようにするための便利な方法を提供する

統合と暗号化の両方を組み合わせる

クラウドベース、マルチテナント、フルマネージドのプラットフォームであるMuleSoft CloudHubなどのESBミドルウェアを介して、クラウドベースとオンプレミスのホストされたアプリケーションのセットと統合されたSalesforceインスタンスがある場合、
エンタープライズのSalesforceインスタンスのみがエンタープライズのMuleSoft CloudHubインスタンスと通信できるようにする必要がある
ここで双方向TLSを使用すると、その機能が提供され、データがセキュリティで保護され、転送時に常に暗号化される

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Becoming a Salesforce Certified Technical Architectの要約（3章：コアアーキテクチャの概念-統合と暗号化-）

3章コアアーキテクチャの概念-統合と暗号化-

概要

ポイント