SAPシステムのクラウド移行が進む中、オンプレミスの基幹システムとSAP BTP（Business Technology Platform）を安全に連携させるハイブリッド環境の構築は企業にとって不可欠です。本記事では、SAP Cloud Connector（SCC）を活用したセキュアなBTP連携手法について、ゼロトラストの観点から詳しく解説します。リバースインボーク接続によりファイアウォールのインバウンドポートを開放せずに安全な通信を確立できるという結論をはじめ、アクセス制御やSSOの実装方法まで網羅しています。
この記事で分かること
- SAP BTPとオンプレミスを繋ぐハイブリッド環境の重要性
- Cloud Connectorによるゼロトラストセキュリティの実現方法
- 証明書を用いたTrust確立とネットワークの堅牢化手法
- プリンシパルプロパゲーション（SSO）による最小特権のアクセス制御
- BTPコックピットと連動した監査ログ管理と監視の仕組み
安全かつ継続的なSide-by-Side拡張を実現するためのベストプラクティスを理解し、堅牢なシステム基盤の構築にお役立てください。
SAP BTPによるSide-by-Side拡張の進展とCloud Connectorが担うゼロトラストの役割
近年、企業の基幹システムであるSAP S/4HANAのアップグレードやクラウド移行に伴い、クリーンコア（基幹システム本体に独自のアドオン開発を行わず、標準機能を維持する方針）の概念が浸透しています。これに伴い、SAP Business Technology Platform（以下、SAP BTP）を活用したSide-by-Side拡張（基幹システムの外側で拡張機能を開発・運用するアーキテクチャ）が主流となっています。本章では、SAP BTPとオンプレミス環境を連携する際の課題と、SAP Cloud Connector（以下、SCC）が果たす役割について解説します。
SAP BTPとオンプレミスを繋ぐハイブリッド環境の重要性
SAP BTP上で提供されるSAP CAP（Cloud Application Programming）フレームワークなどのモダンな開発環境を利用することで、企業はクラウドネイティブなアプリケーションを迅速に構築できます。しかし、これらのクラウドアプリケーションが真の価値を発揮するためには、オンプレミス（自社データセンターやプライベートクラウド）で稼働するS/4HANAなどのバックエンドシステムが保持する業務データと、リアルタイムかつ安全にデータをやり取りするインフラ基盤が不可欠です。
ハイブリッド環境におけるデータ連携は、単なるネットワークの疎通だけでなく、エンタープライズ要件を満たす高度なセキュリティとパフォーマンスが求められます。クラウド上の拡張アプリケーションから社内リソースへのシームレスなアクセスを実現することが、DX（デジタルトランスフォーメーション）推進の要となります。
基幹システムをクラウドへ接続する際のセキュリティリスク
オンプレミスの基幹システムをパブリッククラウドであるSAP BTPと接続する際、従来のネットワーク設計を踏襲することには大きなセキュリティリスクが伴います。一般的な手法としてVPN（仮想プライベートネットワーク）の構築や、ファイアウォールのインバウンドポート（外部から内部への通信許可）を開放するアプローチが考えられますが、これらには以下の課題が存在します。
- ファイアウォールのポート開放による攻撃サーフェス（サイバー攻撃の対象となりうる領域）の拡大
- VPNルーターなどのエッジデバイスに対する脆弱性攻撃のリスク
- BTP上の特定アプリケーションからバックエンドへの細かなアクセス制御（最小特権の原則）の欠如
特に、安易なインバウンド通信の許可は、ランサムウェアなどのマルウェア侵入経路となる脅威をもたらします。また、一度ネットワークレベルで接続を許可してしまうと、BTP上のどのアプリケーションが、社内システムのどのデータ（RFCモジュールやODataエンドポイントなど）にアクセスできるのかを制御・可視化することが難しくなり、重大なガバナンス上の課題を引き起こします。
SAP Cloud Connector（SCC）のリバースインボークによるゼロトラスト実現
これらのセキュリティ課題を解決し、ハイブリッド環境におけるゼロトラスト（すべての通信を無条件に信頼せず、常に検証を行うセキュリティモデル）の考え方をハイブリッド接続に適用するうえで中核となるコンポーネントが、SAP Cloud Connector(以下SCC)です。
SCCの最大の特徴は、リバースインボーク（Reverse Invoke）と呼ばれる通信方式を採用している点です。これは、オンプレミスネットワーク内部に配置されたSCCから、外部のSAP BTPに対して自発的にアウトバウンド通信（内部から外部への接続）を開始し、永続的なセキュアトンネル（TLS暗号化通信）を確立する仕組みです。SAP BTP上のアプリケーションは、この確立されたトンネルを経由してオンプレミスシステムへリクエストを送信します。なお、BTP側でこのトンネルの終端となるのはSAP BTP Connectivityサービスです。アプリケーションはConnectivityサービスにバインドされ、そのプロキシを経由してオンプレミスへのリクエストを送信します。接続先のURLや認証方式はDestinationサービスで一元管理し、実際の通信経路はConnectivityサービスが担う、という役割分担になります。
下表のとおり、従来手法とSCCを利用した連携手法には明確なアーキテクチャの差異があります。
| 比較項目 | 従来手法（VPNやポート開放） | SAP Cloud Connector |
|---|---|---|
| 通信方向 | インバウンド（外部から内部へ） | アウトバウンド（内部から外部へ） |
| ファイアウォール設定 | 外部からの特定ポートの開放が必要 | 内部から外部（HTTPSポート443）のみ許可 |
| アクセス制御の粒度 | ネットワークレベル（IPやポート単位） | リソースレベル（RFC関数やURLパス単位） |
| セキュリティモデル | 境界防御型 | ゼロトラストベース（最小特権の原則） |
BTPサブアカウントとの厳密なTrust確立とネットワークレイヤーの堅牢化手法
SAP BTP（Business Technology Platform）とオンプレミス環境を安全に連携させるためには、アプリケーションレベルの制御だけでなく、インフラストラクチャおよびネットワークレイヤーでの防御が不可欠です。本章では、SAP Cloud Connector（以下、SCC：オンプレミスとクラウドを安全に接続するためのプロキシコンポーネント）を用いた、証明書による厳格な信頼関係（Trust）の構築手法と、ネットワークレベルでの堅牢化アプローチについて解説します。
BTPサブアカウントとSCC間の証明書ベースのTrust管理
SCCとSAP BTPの各サブアカウント（BTP上でのリソースや権限を論理的に分割する単位）を紐付ける際、セキュリティの根幹となるのが証明書ベースの相互認証と暗号化通信（TLS）です。SCCは、BTPに対してアウトバウンドのTLS接続を確立することで、リバースインボーク（内側から外側への通信開始）を実現します。
この接続を確立するプロセスにおいて、SCCはSAP BTPが提供するインフラストラクチャ証明書を信頼し、同時にBTP側もSCCから提示されるクライアント証明書を検証します。これにより、意図しない不正なエンドポイントへの接続や、中間者攻撃（Man-in-the-Middle）を未然に防ぐことが可能です。
証明書のライフサイクル管理においては、初期設定時の登録だけでなく、定期的な更新が求められます。下表のとおり、SCCの設定画面から確認・更新すべき主要なパラメータを整理します。
| 設定項目 | 推奨設定・パラメータ例 | セキュリティ上の意義 |
|---|---|---|
| Region | 例：jp10 (Tokyo) | 接続先のBTPリージョンを限定し、地理的なデータガバナンスを維持します。 |
| Subaccount | 特定のサブアカウントID | 接続先を特定の論理環境に限定し、他環境への誤接続を防止します。 |
| サブアカウント証明書の有効期限 | 期限前の更新計画を運用手順に組み込む | 期限切れによるトンネル断を防ぎ、証明書の更新履歴を監査可能な状態に保ちます。 |
設定手順の詳細や最新の要件については、SAP Help PortalのCloud Connector公式ドキュメントを参照し、常にセキュアな構成を維持してください。
DMZ配置や不要ポート遮断によるインフラレベルの防御
SCCは社内のバックエンドシステム（S/4HANAなど）へ直接アクセスする権限を持つため、SCCサーバー自体のインフラレベルの堅牢化が極めて重要です。SAPの公式ドキュメントでは、SCCの配置先として、DMZ（非武装地帯：外部と内部の中間に位置する境界ネットワーク）に設置してIT部門が集中運用する形と、社内ネットワークに設置して業務部門が運用する形の両方が示されています。どちらを選ぶかは組織の運用体制次第ですが、セキュリティの観点からは、DMZまたは独立したネットワークセグメント上の専用サーバーに配置する構成がよく採用されます。
DMZに配置することで、万が一SCCが侵害された場合でも、社内ネットワーク全体へのラテラルムーブメント（横展開）を遅延・阻止することができます。また、ファイアウォールの設定においては、以下のポリシーを適用します。
- アウトバウンド通信：SCCからSAP BTP（インターネット側）のポート443番（HTTPS）のみを許可する。
- インバウンド通信：インターネットからの直接のインバウンド通信はすべて遮断する。
- 内部通信：SCCからバックエンドシステムへの通信は、必要なホストおよびポートに限定します。RFCの場合はゲートウェイポート（33##、SNC利用時は48##）を開放し、ロードバランシングを利用する場合はメッセージサーバーのホストとポートも対象とします。HTTP/HTTPSの場合は、ICMのサービスポートに限定します。
加えて、SCCを稼働させるOS（LinuxやWindows）自体のセキュリティパッチの定期適用や、不要なOSサービス（デーモン）の無効化など、サーバーハードニング（脆弱性を減らすための基本設定）を徹底することが、ゼロトラスト基盤の土台となります。
- SCCの管理UIは、アクセス制御や証明書を変更できる強い権限を持つ入口です。インストール直後の既定管理者（Administrator）の初期パスワードは必ず変更してください。本番運用では、LDAP連携によって個人単位の名前付きユーザーに切り替え、担当者ごとに必要な権限だけを付与することが推奨されます。これにより、監査ログ上で「誰が設定を変更したか」を特定できるようになります。管理UIのポート（既定値8443）へのアクセスも、運用端末のセグメントからに限定します。
高可用性（HA）構成によるBTP連携の継続性とセキュリティの維持
エンタープライズ環境において、基幹システムとBTPの連携が途絶えることは、ビジネスプロセスの停止を意味します。可用性とセキュリティを両立させるため、SCCではシャドウインスタンス（障害発生時に即座に処理を引き継ぐ待機系サーバー）を利用した高可用性（HA）構成を構築することが可能です。
HA構成を組む場合、マスターインスタンスとシャドウインスタンス間で設定や証明書情報がセキュアに同期されます。この同期通信も暗号化されるため、内部ネットワーク上での情報漏洩リスクは最小化されています。
障害切り替え（フェイルオーバー）が発生した際のアドバンテージは以下の通りです。
- アクセス制御や仮想ホストのマッピングなどの設定はマスターからシャドウへ自動的に同期されるため、切り替え時に設定を手作業で再投入する必要がなく、人為的な設定ミスを防げます。
- シャドウがBTPとのトンネルを再確立するため、BTP側のアプリケーションは接続先を変更することなく通信を再開できます。
- 切り替え後もシャドウ側で監査ログの記録が継続されます。
ただし、HA構成には以下の注意点があります。
- シャドウはCheck Intervalの間隔でマスターの死活を確認し、Takeover Delayの間マスターに到達できなかった場合に役割を引き継ぎます。切り替えまでには設定値に応じたタイムラグがあり、その間のリクエストは失敗します。業務要件に合わせて両パラメータを調整してください。
- プリンシパルプロパゲーションを利用する場合、マスターとシャドウ双方のシステム証明書を、バックエンド側（STRUSTなど）で信頼させておく必要があります。これを怠ると、フェイルオーバー後にSSOが失敗します。
- 管理UIのユーザー管理はマスターとシャドウで個別に設定されるため、両方で同等の管理者設定を行ってください。
このように、HA構成は可用性の向上に加え、障害時の設定不整合によるセキュリティ低下を防ぐ役割も担います。一方で、その効果は上記の事前準備が前提となります。
BTP Destinationサービスと連動した最小特権のアクセス制御とSSO（プリンシパルプロパゲーション）
SAP BTP（Business Technology Platform）とオンプレミスのバックエンドシステムを連携させる際、セキュリティガバナンスの観点から最小特権の原則に基づくアクセス制御が不可欠です。本章では、SAP BTPのDestination（宛先）サービスとCloud Connectorを連動させ、不要なアクセスを遮断するホワイトリスト型の制御手法や、セキュアなシングルサインオン（SSO）を実現するプリンシパルプロパゲーションのアーキテクチャについて解説します。
リソースレベルでのホワイトリスト型アクセス制御
Cloud Connectorの最大の特徴の一つは、オンプレミス環境に対するアクセスを細粒度に制御できる点にあります。デフォルトでは、Cloud Connectorからバックエンドシステムへの通信はすべて拒否される「デフォルトデナイ（Default Deny）」のポリシーが適用されています。そのため、BTP上のアプリケーションからバックエンドのリソースを呼び出すためには、明示的に許可リスト（ホワイトリスト）を定義する必要があります。
このアクセス制御（Access Control）では、単にIPアドレスやポート番号を開放するだけでなく、仮想ホスト（BTP側から見えるダミーのホスト名）と内部ホスト（実際のサーバー名）をマッピングすることで、内部のネットワーク構造を隠蔽します。さらに、HTTP/HTTPS通信であれば特定のODataエンドポイント（URLパス）、RFC通信であれば特定のRFC汎用モジュール名といった、リソースレベルでの極小化されたアクセス許可が可能です。
設定パラメータの例は下表のとおりです。
| 設定項目 | 説明 | 設定例 |
|---|---|---|
| Virtual Host / Port | BTPのDestinationに設定する仮想的なホスト名とポート | s4hana-virtual:443 |
| Internal Host / Port | オンプレミス環境内の実際のホスト名とポート | s4hana-internal.local:8443 |
| URL Path / RFC Name | 許可する具体的なリソース（パスやモジュール名） | /sap/opu/odata/sap/API_SALES_ORDER_SRV |
| Access Policy | 指定したパスのみ許可するか、サブパスも含めるか | Path and all sub-paths |
このように設定を極小化することで、万が一BTP上のアプリケーションが侵害された場合でも、許可されていない他のバックエンドAPIやRFCモジュールへのアクセスを、Cloud Connectorの段階で拒否できます。詳細な設定手順や仕様については、SAP公式のCloud Connectorドキュメントも併せて参照してください。
SAP Cloud Identity Services（CIS）を介したアイデンティティの伝播
BTPを用いたSide-by-Side拡張開発において、ユーザーのアイデンティティ（誰が操作しているか）をバックエンドシステムまで安全に引き継ぐことは、監査や権限管理の観点で非常に重要です。これを実現する仕組みがプリンシパルプロパゲーション（Principal Propagation）です。
通常、クラウドとオンプレミス間の認証では、技術ユーザー（固定のシステムアカウント）を用いた連携が行われがちですが、これではバックエンド側で「どの業務ユーザーがデータ更新を行ったか」を特定できません。プリンシパルプロパゲーションを利用することで、個別ログオンなしでバックエンド処理を実行しつつ、ユーザーのアイデンティティを伝播させることが可能になります。
具体的なアーキテクチャの流れは以下のようになります。
-
ユーザーがIdP（SAP Cloud Identity Services – Identity Authenticationなど）を介してBTP上のアプリケーションにログインし、アプリケーションは認証済みユーザーのJWT（JSON Web Token）を保持します。
-
アプリケーションはBTPのDestinationサービスから接続先情報（Proxy Type: OnPremise、Authentication: PrincipalPropagation、Location IDなど）を取得します。
-
アプリケーションはSAP BTP Connectivityサービスのプロキシに対してリクエストを送信します。このとき、ユーザーのJWTはSAP-Connectivity-Authenticationヘッダーに付与されます。プロキシは、Cloud Connectorが確立済みのトンネルを経由してリクエストを転送します。SAP Cloud SDKやCAPを利用する場合、この処理はライブラリが自動で行います。
-
Cloud Connectorは、BTPサブアカウントから同期した信頼済みIdPの情報をもとにJWTを検証します。そのうえで、あらかじめ定義したサブジェクトパターン（例：CN=${name}）に従い、短寿命のX.509証明書を動的に生成します。
-
HTTPS接続の場合、バックエンドとのTLS通信はCloud Connectorのシステム証明書で確立されます。短寿命証明書はSSL_CLIENT_CERTヘッダーでバックエンドに渡されます。バックエンド側（ICM）はCloud Connectorを信頼済みのリバースプロキシとして扱い、CERTRULEトランザクションなどのルールに基づいて証明書を業務ユーザーにマッピングします。RFC接続の場合は、SNC（Secure Network Communications）を用いた構成が別途必要です。【要確認：ICMの信頼済みプロキシ関連パラメータ名、RFCでのSNC設定要件】
この仕組みにより、パスワードをネットワーク上に流すことなく、セキュアなSSO環境を構築できます。
開発・本番などBTPサブアカウント単位での厳密なリソース分離
企業がBTPを活用する際、開発（Dev）、検証（Test）、本番（Prod）といった複数の環境を構築するのが一般的です。これらの環境が誤ったバックエンドシステムに接続してしまうリスクを排除するため、BTPサブアカウント単位での厳密なリソース分離が求められます。
Cloud Connectorでは、1つのインスタンスから複数のBTPサブアカウントに対してトンネルを確立することが可能です。この際、Location ID（ロケーションID）という識別子を活用することで、BTPのDestinationサービスから特定のCloud Connectorや特定のネットワーク経路を論理的に指定することができます。
セキュアなリソース分離を実現するためのマッピング戦略として、以下の構成を推奨します。
- 環境ごとのCloud Connector分離：本番環境用と非本番環境用でCloud Connectorのサーバー（OS）自体を物理的または論理的に分割し、不要な通信経路を根絶します。
- Location IDの必須化：すべての接続設定においてLocation IDの入力を必須とし、Destination設定ミスによる他環境への意図しないアクセスを防止します。
- サブアカウントごとのTrust確立：BTPサブアカウントごとに個別の証明書を用いてTrust（信頼関係）を確立し、環境間のアイデンティティの混入を防ぎます。
このように、ネットワークレイヤーとアプリケーションレイヤーの両面から境界を設けることで、エンタープライズレベルのセキュリティ要件を満たす堅牢なハイブリッドクラウド環境を維持することができます。
BTPコックピットと連動した不正アクセス検知および統合的な監査ログ管理
SAP BTP（Business Technology Platform）とオンプレミス環境を連携するハイブリッドアーキテクチャにおいて、セキュリティガバナンスを維持するためには、継続的な監視とログの取得が不可欠です。本章では、SAP Cloud Connector（以下、SCC：オンプレミスとクラウドを安全に繋ぐエージェント）の監査ログ設定や、BTPコックピット（BTPの統合管理画面）を利用した監視スキーム、さらに最新の暗号化規格を維持するライフサイクル管理について解説します。
Cloud Connector上の監査ログ有効化とコンプライアンス維持
SCCは、オンプレミスの基幹システム（S/4HANAなど）に対するゲートウェイとして機能するため、「誰がいつSCCの設定を変更したか」「BTPからのどのリクエストが拒否されたか」を正確に記録することがコンプライアンス維持の観点で重要です。SCCの管理UI（Administration UI）には、監査ログ（Audit Log）機能が標準で備わっており、これを適切に設定することで不正アクセスの検知や事後調査が可能になります。
監査ログの取得において推奨される設定項目とパラメータ例は、下表のとおりです。
| 設定項目 | 選択肢 | 推奨設定 | 記録される内容 |
|---|---|---|---|
| Subaccount Audit Level | Security / All / Off | Security（既定値）。法令や社内規程で求められる場合はAll | Security：アクセス拒否されたリクエスト、公開バックエンドや許可リソースなど重要な設定変更。All：上記に加え、許可されたアクセスもすべて記録 |
| Cross-subaccount Audit Level | Security / All / Off | Security（既定値） | サブアカウントに依存しないコネクター全体の設定変更 |
| Automatic Cleanup | 14〜365日 | 社内の保存規程に合わせて設定（外部保管と併用） | 期間を過ぎた監査ログファイルの自動削除 |
SAPは、本番環境では監査ログを常時有効にし、通常はSecurityレベルで運用することを推奨しています。Offは監査証跡が失われるため選択すべきではありません。
なお、トラブルシューティング用のペイロードトレース（HTTP/RFCの通信内容の記録）は監査ログとは別の機能です。パスワードなどの機密情報が記録される可能性があるため、問題の再現時のみ一時的に有効化し、取得後は速やかに無効化してください。Linux環境では、トレースの有効化に二人承認を強制する設定も可能です。
特に、アクセス制御で拒否されたリクエストの記録は、ゼロトラストアーキテクチャ（すべての通信を信頼せず検証するセキュリティモデル）の有効性を評価する上で重要な指標となります。監査ログは、デジタル署名付きのCSVファイルとして、SCCインストールディレクトリ配下の log/audit/<サブアカウント名>/ に出力されます。署名によってファイルの改ざんを検知できるほか、SAPは社内規程に従い外部の永続ストレージへ定期的にコピーすることを推奨しています。SIEM（Security Information and Event Management：統合ログ管理システム）と統合する場合は、ログ収集エージェントでこれらのファイルを取り込む構成が一般的です。バージョン2.14以降では、監査ログの出力先ディレクトリを変更することもできます。
SAP BTPコックピットからの接続ステータスとトンネルの監視
SCCからBTPへの通信は、リバースインボーク（内部から外部へのアウトバウンド通信）によってセキュアなTLSトンネルを確立します。このトンネルの死活監視は、BTP上のアプリケーションの可用性に直結するため、SAP BTPコックピットを活用したリアルタイムな監視スキームの構築が求められます。
BTPコックピットの「Cloud Connectors」メニューでは、各サブアカウント（BTP上の論理的なリソース分割単位）に接続されているSCCのステータスを一元的に確認できます。監視すべき主なポイントは以下のとおりです。
- Connection Status（接続状態）： Connected（接続済み）かDisconnected（切断）かを監視します。
- Exposed Backends（公開されたバックエンド）： 意図しないオンプレミスシステムがBTP側に公開されていないかを定期的に棚卸しします。
- High Availability Status（高可用性ステータス）： SCCを冗長化（HA構成）している場合、マスター機とシャドウ機（待機系）の同期状態が正常であることを確認します。
さらに、運用を自動化するための手段として、SCC自体のアラート機能があります。管理UIでメール通知を設定すると、トンネルの切断や自動テイクオーバーの発生を管理者へ通知できます。全社的な運用監視に組み込む場合は、SAP Cloud ALM（Application Lifecycle Management）のHealth MonitoringでSCC（バージョン2.13.0以上）を監視対象として登録する方法があります。
最新の暗号化スイート維持と定期的なパッチ適用のライフサイクル
BTP連携のセキュリティを強固に保つためには、インフラストラクチャレベルでの継続的なメンテナンスが不可欠です。SCCはJavaベースのアプリケーションであり、内包されるJVM（Java Virtual Machine）やOSの脆弱性に対応するため、定期的なパッチ適用とバージョンアップのライフサイクルを回す必要があります。
また、通信の暗号化に用いられるTLS（Transport Layer Security）のバージョンや暗号化スイート（Cipher Suite）も、変化するセキュリティ要件に合わせて最新化しなければなりません。
- TLSバージョンの制限： 古い規格であるTLS 1.0や1.1は無効化し、TLS 1.2以上（可能であればTLS 1.3）のみを許可するようにSCCのプロパティファイル（server.xmlなど）を設定します。
- 強力な暗号化スイートの選択： 脆弱性が指摘されている暗号化アルゴリズム（RC4や3DESなど）を排除し、前方秘匿性（PFS：過去の通信が後から解読されるのを防ぐ仕組み）を持つECDHEなどのアルゴリズムを優先的に使用します。
- 定期的なアップデート： SAP社から提供されるSCCの最新パッチには、セキュリティ修正だけでなくパフォーマンス改善も含まれます。検証環境でのテストを経た上で、計画的に本番環境へ適用する運用プロセスを定義します。
これらの設定と運用プロセスを徹底することで、SAP BTPとオンプレミス間の通信経路における盗聴や改ざんのリスクを極小化し、エンタープライズ水準のセキュアなハイブリッドクラウド環境を長期的に維持することが可能になります。
セキュアなBTP連携を確立するための要件定義から実機検証までのステップ
BTP（SAP Business Technology Platform）とオンプレミス環境の連携において、SAP Cloud Connector（SCC）を利用したセキュアな通信基盤を構築するためには、要件定義から実機検証（PoC：概念実証）までの確実なステップを踏むことが不可欠です。本章では、ゼロトラストアーキテクチャを実現するための具体的な導入プロセスと、将来を見据えた拡張ロードマップについて解説し、全体の総括とします。
BTPアプリが要求するバックエンドリソースの事前棚卸
SAP BTP上のクラウドネイティブアプリケーションが、オンプレミスのバックエンドシステム（S/4HANAなど）と連携する際、まずは必要となるリソースを正確に特定するアセスメントを実施します。このプロセスを怠ると、過剰な権限付与によるセキュリティリスクを招く可能性があります。
具体的には、対象となるAPI、RFC（Remote Function Call：SAPシステム間の標準的な通信プロトコル）、OData（Open Data Protocol：RESTful APIの標準規格）のエンドポイントを洗い出し、最小特権の原則に基づいてアクセス制御ポリシーを定義します。
下表のとおり、リソースの種類に応じた棚卸し項目を整理し、SCCの「Access Control（アクセス制御）」設定に反映させます。
| リソース種別 | 確認項目 | SCCでの設定パラメータ例 |
|---|---|---|
| RFCモジュール | 呼び出し元アプリ、対象の汎用モジュール名 | Function Name: BAPI_SALESORDER_GETLIST, Match: Exact |
| OData / HTTP | アクセス先URLパス、HTTPメソッド（GET/POST等） | URL Path: /sap/opu/odata/sap/API_SALES_ORDER_SRV, Access Policy: Path and all sub-paths |
| データベース（TCP接続） | 接続先ホスト、ポート | Protocol: TCP、Internal Host / Port を個別に指定（※TCP接続ではURLパスやクエリ単位の制御はできないため、DB側のユーザー権限で最小特権を担保します） |
実機検証における意図的なアクセス遮断や証明書切れの挙動テスト
要件定義と設定が完了した後は、本番稼働に向けた実機検証を実施します。ここでは、正常系の通信テストだけでなく、異常系やセキュリティ境界が正しく機能しているかを確認するテストが重要です。
特に、SAP公式ドキュメントでも解説されているように、BTP Destinationサービス（BTP側で接続先情報を一元管理する機能）とSCC間の通信において、意図したアクセス制御が機能しているかを厳密に検証します。
実機検証で実施すべき主なテスト項目は以下のとおりです。
- ホワイトリストに登録されていないURLパスやRFCモジュールへのアクセスがSCCで確実に拒否（Deny）されるかの確認
- BTPサブアカウントとSCC間のTrust（信頼関係）に利用される証明書を意図的に無効化、または期限切れ状態にし、通信が遮断されることの確認
- プリンシパルプロパゲーション（ユーザーIDの伝播）において、権限を持たないユーザーのバックエンド処理が拒否されるかの確認
これらのテストを通じて、設定ミスによる意図しないポート開放や情報漏洩のリスクを未然に防ぐことが可能になります。
セキュアなBTP活用を支えるインフラ拡張のロードマップ
初期設定と検証が完了し、セキュアなBTP連携基盤が確立された後は、全社的な拡張開発（Side-by-Side拡張）を支えるインフラへと成長させるための段階的なアプローチが必要です。ゼロトラストアーキテクチャの維持には、継続的な監視と運用改善が欠かせません。
ロードマップの初期段階では、SCCの監査ログの有効化とBTPコックピットからの接続ステータス監視を定着させます。次の段階として、開発・検証・本番といった環境ごとにBTPサブアカウントとSCCのマッピングを論理的に分離し、ガバナンスを強化します。最終的には、高可用性（HA）構成の導入と、拠点ごとのLocation IDによる経路設計や、最新の暗号化スイート（TLS 1.3など）への定期的なアップデートサイクルを確立します。
SAP BTPとオンプレミスを繋ぐハイブリッド環境において、SAP Cloud Connectorは単なる中継サーバーではなく、企業の基幹データを守る強固なセキュリティゲートウェイとして機能します。本記事で解説した証明書ベースのTrust確立、最小特権のアクセス制御、そして継続的な監視運用を組み合わせることで、安全かつ柔軟なクラウドネイティブ開発を推進する堅牢な基盤を構築することができます。
よくある質問
SAP Cloud Connectorの高可用性（HA）構成における推奨構成はどのようなものですか？
SAP Cloud Connector（以下、SCC）を高可用性（HA）構成でデプロイする場合、マスターインスタンスとシャドウインスタンスを用いた冗長化構成がベストプラクティスとされています。この構成により、ハードウェア障害やOSのパッチ適用時においても、SAP BTP上のアプリケーションからオンプレミス（S/4HANAなどの社内バックエンド）への通信断を最小限に抑えることが可能です。
マスターとシャドウの役割および切り替え時の動作については、下表のとおり整理できます。
| コンポーネント | 役割と平常時の状態 | 障害発生時の挙動（フェイルオーバー） |
|---|---|---|
| マスターインスタンス | BTPサブアカウントとのアクティブなTLSトンネルを維持し、すべてのトラフィックを処理します。 | 障害検知時、自動的にシャドウインスタンスへ役割を引き継ぎます。 |
| シャドウインスタンス | 平常時はスタンバイ状態であり、マスターから設定情報や証明書を同期します。 | 一定間隔（Check Interval）でマスターの死活を確認し、応答がない状態が一定時間（Takeover Delay）続くと、アクティブ状態に昇格してBTPとの接続を再確立します。 |
HA構成を組む際は、両インスタンスを物理的に異なるサーバーやアベイラビリティゾーンに配置することが推奨されます。シャドウインスタンスは、マスターの管理UIのホスト名とポート（既定値は8443）に接続して設定を同期し、死活監視を行います。そのため、シャドウからマスターの管理UIポートへの通信を、内部ネットワークのファイアウォールで許可しておく必要があります。
プリンシパルプロパゲーション（SSO）設定時に発生しやすいエラーと対処法を教えてください。
SAP BTP側で認証されたユーザー情報をオンプレミスへ安全に引き継ぐプリンシパルプロパゲーション（アイデンティティの伝播）は、設定が複雑であり、いくつか典型的なトラブルシューティングのポイントが存在します。エラーが発生した場合、まずはSCCの監査ログやトレースレベルを上げて原因を特定します。
主な確認ポイントは以下のとおりです。
- システム証明書の信頼関係（Trust）の欠如：Cloud Connectorのシステム証明書の発行者（CA）の証明書が、バックエンドシステムのSTRUSTトランザクションで信頼リストに登録されているかを確認します。登録するのはシステム証明書そのものではなく、発行者の証明書である点に注意してください。あわせて、短寿命証明書の発行者とサブジェクトが、CERTRULEのマッピングルールと一致しているかも確認します。
- サブジェクトパターンの不一致：BTPから渡されるユーザーID（メールアドレスなど）と、バックエンドシステムのユーザーマスター（SU01）のエイリアスや名称がマッピングルールと一致しているか確認します。
- プロファイルパラメータの不足：バックエンドのSAPシステムにおいて、SNC（Secure Network Communications）やICM（Internet Communication Manager）のパラメータがSSOを受け入れるよう正しく設定されているか確認します。
特に、ユーザーIDのマッピングエラーは頻出するため、SAP Cloud Identity Services（CIS）側で渡す属性情報と、バックエンド側で期待する識別子を厳密に一致させることが重要です。
複数のBTPサブアカウントを運用する場合、Cloud Connectorはどのように配置・管理すべきですか？
開発（Dev）、検証（Test）、本番（Prod）のように複数のBTPサブアカウントを運用する場合、セキュリティガバナンスとリソース分離の観点から、本番環境と非本番環境でSCCのインスタンスを物理的または論理的に分離することが強く推奨されます。
1つのSCCから複数のサブアカウントへ接続することは技術的に可能ですが、1つの設定ミスがすべての環境に影響を及ぼすリスクがあります。そのため、下表のとおり環境ごとにSCCを分割し、最小特権のアクセス制御（ホワイトリスト型制御）を適用するのが一般的です。
| 環境 | SCCの配置戦略 | アクセス制御（Access Control）のポイント |
|---|---|---|
| 本番環境（Prod） | 専用のHA構成SCCを構築 | 本番用バックエンドシステムのみを許可し、実行可能なRFCモジュールやODataエンドポイントを極小化してホワイトリストに登録。 |
| 非本番環境（Dev/Test） | 共有の単一SCC（またはHA構成）を構築 | 開発機・検証機へのアクセスのみを許可し、本番データへの誤アクセスをネットワークレイヤーで根絶。 |
このようにBTPサブアカウント単位で厳密なリソース分離を行うことで、ゼロトラストアーキテクチャの原則に沿ったセキュアなハイブリッド環境を維持することができます。
