セキュリティ
データのプライバシーと、e コマースシステムへのアクセスの信頼性を保証することは、B2C Commerce プラットフォームにおける最重要事項です。B2C Commerce API とのすべてのインタラクションは、完全に認証され、承認される必要があります。
B2C Commerce は、ヘッドレスコマースのための認証、認可、可用性の機能を提供します。
認証とは、クライアント (たとえば、PWA Kit のストアフロント) が本人であることを確認するために、身元を検証することです。管理者は、API クライアントにシークレット (パスワードのようなもの) をプロビジョニングします。クライアントはこのシークレットを使ってアクセストークンをリクエストします。API ゲートウェイはアクセストークンに基づいてクライアントの本人確認を行います。
認可は、特定のリソースへのアクセスを検証し、クライアントが特定のタスクを実行する許可をもっていることを確認することです。管理者は、API クライアントに許可を割り当てる範囲をプロビジョニングします。API クライアントはアクセストークンをリクエストする際に、範囲のセットを指定します。API ゲートウェイはアクセストークンに基づいて認可を行います。詳細については、認可を参照してください。
可用性は、サービスが常に稼働していることを保証するものです。ヘッドレスコマースでは、DoS 対策と API レート制限により可用性を実装しています。詳細については、レート制限を参照してください。
カスタムヘッドは顧客のインフラとアプリケーションスタック上で実行されるため、B2C Commerce の顧客は、プレゼンテーションレイヤーと BFF レイヤーの両方を含むカスタムヘッドのセキュリティを保護する責任があります。この責任を担う意思と能力があるかどうかを自問して確認してください。トラフィックの多い一般向けアプリケーションの構築、ホスティング、およびメンテナンスには多大な労力が伴う可能性があります。
Salesforce は、顧客のカスタムヘッドに公開される API エンドポイント、および顧客の Commerce リソースがホストされている B2C Commerce プラットフォームのセキュリティを保護する責任を担います。
可用性は、サービスが常に稼働していることを保証するものです。ヘッドレスコマースでは、DoS 対策により可用性を実装しています。
ヘッドレスコマース用に開発を行う場合は、深層防護やセキュアデフォルトなど、すべての一般的なセキュリティの原則に従ってください。一般的なセキュリティのベストプラクティスに記載されているベストプラクティスを用いて、セキュリティの脅威に対する最大限の保護をサイトに実装してください。
実装時には、セキュアな設計とコーディングのプラクティスを使用します。Open Web Application Security Project (OWASP) が提供するリソースを確認することが推奨されます。OWASP は、Web アプリケーションのセキュリティに関する記事、方法論、ドキュメント、ツール、テクノロジーを提供するオンラインコミュニティです。
ヘッドレスコマースアーキテクチャを開発する際には、B2C セキュリティのベストプラクティスに従ってください。
ここで説明する B2C セキュリティのベストプラクティスの実施に加え、顧客は責任共有モデルの一環として、自社のフロントエンドインフラにセキュリティを実装する責任も担うことになります。
最小権限の原則に従い、API クライアント、ユーザー、アプリケーション、システム、その他のコンポーネントには、それぞれのジョブに必要な最小限の権限レベルのみを与えるようにしてください。Account Manager で API クライアントをプロビジョニングする際には、最小権限の原則を実装します。また、API クライアントが Account Manager に JWT アクセストークンをリクエストする際にも、最小権限を適用します。クライアントが API を呼び出すと、API ゲートウェイはアクセストークンに基づいて認可を行います。
認可で説明したとおり、B2C Commerce のヘッドレスモデルでは、OAuth の範囲を使って API クライアントの許可を定義します。API クライアントのプロビジョニングプロセスの一貫として、管理者は、その API クライアントの許可範囲とデフォルト範囲の両方を指定します。JWT アクセストークンをリクエストする際、API クライアントは JWT アクセストークンに含まれる範囲のセットをリクエストできます。
API クライアントが範囲をリクエストしない場合、API クライアントに返される JWT アクセストークンには、「デフォルト範囲」セクションで指定された範囲が含められます。API クライアントが範囲をリクエストし、その範囲が API クライアントの許可範囲にプロビジョニングされている場合、リクエストされた範囲は JWT アクセストークンに含められます。Account Manager で API クライアントをプロビジョニングする際には、最小権限の原則を適用します。たとえば、ある API クライアントが Catalogs API へのアクセスのみを必要とする場合、そのクライアントの Catalogs API に関連する範囲のみをプロビジョニングします。
範囲を追加すると、クライアントに必要以上の権限を与えることになるため、そのクライアントには、他の API の範囲をプロビジョニングしないでください。同様に、API クライアントが Product API への読み取りアクセスのみを必要とする場合、API クライアントに Product API の読み取り/書き込み範囲を構成しないようにします。末尾が .rw の範囲では読み取りと書き込みの両方のアクセスが指定され、末尾が .rw でない範囲では読み取りアクセスのみが指定されます。
次の例は、Catalogs API への読み取り/書き込みアクセスおよび Product API への読み取り専用アクセスで構成される API クライアントにプロビジョニングされる範囲を示しています。
API クライアントが Account Manager に JWT アクセストークンをリクエストする際には、最小権限を適用します。たとえば、ある API クライアントが、Catalogs API と Products API の両方へのアクセス権をプロビジョニングされたとします。API クライアントが Products API のみを必要とする場合、API クライアントはアクセストークンにその範囲のみをリクエストします。API クライアントが後で Catalogs API を呼び出さなければならなくなった場合、クライアントは Catalogs 範囲をリクエストできます。
ヘッドレスコマースアプリケーションのパフォーマンス、スケール、セキュリティをメンテナンスする方法については、以下のドキュメントを参照してください。