Cloud Connector: アーキテクチャと用途

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 12, 2026 · 23 min read

本記事の位置づけ#

参考資料#

1) 基盤サービスランドスケープ#

Cloud Connectorは単独で動作するわけではありません。これは、クラウドとオンプレミスシステム間のすべての接続を処理するSAP BTP基盤サービスのスタックにおける1つのコンポーネントです。統合を設計する前に、各コンポーネントの役割を理解することが不可欠です。

これらは代替手段ではありません。Cloud Connectorは企業ネットワーク経由で到達するオンプレミスシステムを扱い、Private Linkは同一ハイパースケーラー上のクラウドホスト型サービスを扱います。両方を使用するお客様は一般的です。

2) S/4HANA への接続方法#

Cloud Connectorは、BTPアプリケーションとS/4HANAバックエンド間の4ホップのリクエストチェーンにおけるオンプレミス側の役割を担います。このチェーンの重要な特性は、トンネルが常に企業ネットワークからアウトバウンドで開始されることです。クラウド側がインバウンド接続を開くことはありません。このリバースインボークモデルが、 Cloud Connectorアーキテクチャの基盤となっています。

BTP Application (CF)
    |
    | (1) Resolve Destination (Proxy Type: OnPremise, Virtual Host, Location ID)
    v
Destination Service
    |
    | (2) Route via active Cloud Connector tunnel
    v
BTP Connectivity Service  ←→  [persistent TLS tunnel on port 443, outbound]
                                      |
                               Cloud Connector (on-premise host in DMZ)
                                      |
                               (3) Apply access-control allowlist
                                      |
                               (4) Forward to real backend host
                                      v
                              S/4HANA (ABAP) / BW / Gateway
                              (real internal hostname never exposed to BTP)

重要ポイント: Cloud Connectorで設定された仮想ホスト/ポートは、BTPから見える唯一のネットワーク識別子です。実際の内部ホスト名が企業ネットワークの外部に出ることは決してありません。この分離はオプションではなく、アーキテクチャの主要なセキュリティ保証であり、開発サブアカウントであっても維持されなければなりません。

RFC接続の場合、SAP Java Connector（JCo）はBTPアプリケーション側で動作し、同じトンネルを介して通信します。HTTP接続の場合は、標準のHTTP/HTTPSサービスチャネルが使用されます。

3) 成熟度マップ#

以下の表は、Cloud Connector の各機能の v2.19.0.2 時点でのプロダクション対応状況を示しています。完全なバージョン履歴と新たにサポートされたプラットフォームについては、SAP Help Portal の Cloud Connector ドキュメントを参照してください。

4) 要件チェックリスト#

インフラストラクチャおよびプラットフォームの前提条件#

このチェックリストを完了する前に、 Linux OS へのインストールを参照して、サポート対象の OS 一覧とデーモン設定の手順を確認してください。

テナントおよび契約の前提条件#

アクセス制御とセキュリティ要件#

Cloud Connector Securityのドキュメントでは、セキュリティ管理と証明書要件の全セットを規定しています。本チェックリストは、実装開始前に確認すべき要件段階の項目を網羅しています。

プリンシパル伝播の前提条件（該当する場合）#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. この接続がない場合、どの特定のオンプレミス統合がブロックまたは機能しなくなりますか？

具体的に述べてください。「BTP拡張機能からBAPI_SALESORDER_CREATEFROMDAT2を呼び出す必要がある」は有効な回答です。「オンプレミスに接続する必要がある」は不十分です。チームが特定のバックエンド、ファンクションモジュール、HTTPパスを指定できない場合、その要件は実装の準備ができていません。 Cloud Connectorの設定は許可リストに完全に依存します。許可する内容がわからなければ、デプロイメントは過剰に許可（セキュリティリスク）または過小に許可（統合の破綻）のいずれかになります。

Q2. 公開されるオンプレミスシステムの所有者は誰ですか。また、システムマッピングを承認していますか。

Cloud Connector は、BTP 上でホストされるアプリケーションに対して内部システムを公開します。バックエンドシステムを管理する Basis チームは、すべてのシステムマッピングとアクセス制御エントリをレビューし、承認する必要があります。Basis の承認なしに Cloud Connector を設定したプロジェクトは、セキュリティチームが許可リストを監査する際に、緊急変更に直面することがよくあります。

Q3. 特定のBasisレベルのスキルを持つプラットフォームエンジニアと、継続的なメンテナンス予算は確保されていますか？

Cloud Connector のバージョンは、正確に 12 か月間サポートされます。HA アップグレード、証明書のローテーション、アクセス制御の変更、監査ログのレビューは、定期的な運用タスクです。指名された所有者と割り当てられた時間がなければ、Cloud Connector は資産ではなくセキュリティ上の負債となります。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害 1: デフォルト認証情報がそのまま残っている

Cloud Connector にはデフォルトのログイン情報 Administrator / manage が設定されています。これらの認証情報は公開ドキュメントに記載されています。開発環境やQAインスタンスを含め、本番稼働前にこれらを変更せずに運用したプロジェクトは、監査で頻繁に指摘されます。Cloud Connector をインストールした後の最初のステップとして、必ず Administrator パスワードを変更し、本番環境ではファイルベースの認証を LDAP に置き換える必要があります。完全な認証情報の強化ガイダンスについては、 Cloud Connector セキュリティ を参照してください。

障害 2: 過度に広範なアクセス制御の許可リスト

初期設定時には、HTTPシステムにルートパス/へのアクセスを許可したり、RFCファンクションモジュールにワイルドカードプレフィックスを使用したりしたくなります。これにより初期テストはパスしますが、統合アクセスを想定していなかったICFデバッグサービス、管理エンドポイント、ファンクションモジュールが公開されてしまいます。アクセス制御エントリは、本番稼働前に実際の統合シナリオのリストと照らし合わせてレビューする必要があります。明示的な許可リストモデルについては、 アクセス制御の設定（RFC）を参照してください。

障害 3: 本番環境向けの単一 Cloud Connector インスタンス

HA（高可用性）を備えていないCloud Connectorは、すべてのオンプレミス統合における単一障害点となります。ホストがパッチ適用、再起動、またはハードウェア障害でダウンすると、BTPからオンプレミスへのすべての統合が停止します。プロジェクトでは、最初の本番障害が発生するまで、この運用上の影響を一貫して過小評価しています。すべての本番環境のデプロイメントでは、マスター・シャドウHAペアを使用する必要があります。本番稼働開始前には、 高可用性セットアップのドキュメントを参照してください。

障害4: ロケーションIDが未定義 — または重複するロケーションID

複数のCloud Connectorが同一のBTPサブアカウントに接続する場合、Destination ServiceはLocation IDを使用してリクエストを正しいトンネルにルーティングします。Location IDが空白または重複していると、宛先ベースのルーティングは未定義となります。典型的な症状としては、再現が極めて困難な断続的な接続障害が発生します。Location IDは計画、文書化され、Cloud Connector管理UIとBTP Destination設定の両方で一貫して設定する必要があります。

障害5：証明書の有効期限が監視されていない

Cloud Connector は、X.509 証明書を3つの異なる目的で使用します。UI TLS 証明書、BTP トンネル確立に使用するシステム証明書、および（プリンシパル伝播を使用する場合の）短期ユーザー証明書です。それぞれに有効期限があります。アラートを設定していない場合、期限切れの証明書は、本番インシデント対応時に診断が困難な不可解な接続障害を引き起こします。Cloud Connector 管理 UI で、すべての証明書の有効期限が切れる少なくとも30日前に期限切れアラートを設定してください。完全な証明書管理ガイダンスは、 Cloud Connector セキュリティ を参照してください。

障害 6: 12か月のサポート期間を超えたアップグレードの延期

各Cloud Connectorバージョンのサポート期間は正確に12ヶ月です。Cloud Connectorを「設定したら放置」するインフラと見なす組織は、すぐにサポート対象外のバージョンを実行することになります。SAPは、定期的なアップグレードの障壁を取り除くために、ダウンタイムゼロのHAアップグレード手順を正確に提供しています。12ヶ月のアップグレードサイクルを計画しないと、セキュリティパッチを受けられないサポート対象外のインスタンスが蓄積されます。

障害 7: アップグレード前に設定がバックアップされていない

Cloud Connector はすべての設定をローカルファイルシステムに保存します。データベースを利用するアプリケーションとは異なり、自動設定バックアップは行われません。アップグレードやホスト移行の前には、管理者は管理 > 設定 > エクスポートから設定をエクスポートし、両方のHAノードのOSレベルのスナップショットを取得する必要があります。この手順を省略したプロジェクトでは、アップグレード失敗後に完全な再設定が必要となり、どのバックエンドがマッピングされていたか、どのパスが許可されていたかの記録も失われます。

FAQ#

Q: Cloud Connector は SAP アプリケーションサーバーと同じホストにインストールできますか？

いいえ — これは単なる好みではなく、厳格なセキュリティ推奨事項です。Cloud Connector を SAP アプリケーションサーバーにインストールすると、Cloud Connector プロセス（アウトバウンドのインターネット接続を持つ）が侵害された場合、ABAP ファイルシステムとメモリに直接アクセスされる可能性があります。Cloud Connector は DMZ 内の専用ホスト上で実行し、ファイアウォールルールで SAP BTP へのポート 443 上の特定のアウトバウンドトラフィックと、許可リスト内の特定のバックエンドホストへのインバウンドコールのみを許可する必要があります。

Q: Cloud Connector には VPN が必要ですか？

いいえ。Cloud Connectorの基本設計により、VPNは不要です。コネクタはポート443でアウトバウンドTLSトンネルを確立します。このポートは、企業のファイアウォールポリシーでもアウトバウンドトラフィックとしてほぼ常に許可されています。これが「リバースインボーク」モデルです。クラウド側がインバウンド接続を開始することはありません。VPN、インバウンドファイアウォールルール、およびインターネットからのインバウンド接続を許可するDMZルールは一切不要です。

Q: Cloud Connectorのライセンス費用はいくらですか？

Cloud Connector ソフトウェア自体は、SAP BTP エンタイトルメントの一部として無料でダウンロードおよび使用できます。Cloud Connector に個別のライセンス料はかかりません。実際のコストはインフラストラクチャ、つまり専用ホスト（HA の場合は 2 台）、それを維持するための運用負荷、および各サブアカウントの BTP Connectivity サービス エンタイトルメントです。プロジェクトでは、初期予算見積もりで専用ホストのコストを見落とすことがよくあります。

Q: プロジェクトからCloud Connectorを除外すべきタイミングはいつですか？

Descope Cloud Connectorは、接続先となる本物のオンプレミスバックエンドが存在しない場合に使用します。ターゲットシステムがすでにクラウド上にある場合（例：S/4HANA Cloudのサブスクリプションベースのインスタンス、またはBTPと同じクラウドプロバイダー上でホストされているハイパースケーラーサービス）、Private Link Serviceまたは直接のアウトバウンド接続の方が適切であることが多いです。Cloud Connectorはレイテンシと運用オーバーヘッドを追加するため、企業ファイアウォールの背後にあるシステムにアクセスする場合にのみ正当化されます。

Q: プロジェクトにおいてCloud Connectorの要件を適切に文書化するにはどうすればよいですか？

各システムマッピングについて、以下を文書化する：実際のバックエンドホスト名とポート、仮想ホスト名とポートエイリアス、プロトコル（HTTP/RFC）、許可リスト内の特定のパスまたはファンクションモジュールプレフィックス、認証方式（Basic、プリンシパル伝搬、クライアント証明書）、およびマッピングを承認したバックエンドシステムの所有者。この文書は、構成リファレンスとして、またセキュリティ監査の証拠として機能する。Cloud Connector管理UIのコメントのみに保存するのではなく、プロジェクトのアーキテクチャ決定記録に保存すること。

Q: Cloud Connector マスターが障害で停止し、シャドウが引き継いだ場合、アクティブな接続はどうなりますか？

フェイルオーバー発生時に処理中のアクティブなリクエストは失敗し、呼び出し元アプリケーションによる再試行が必要です。シャドウが新しいマスターとなり、BTPトンネルを再確立します。新しいリクエストは通常通り処理されます。アプリケーションは、再試行ロジックを用いて一時的な接続エラーを処理できるよう設計する必要があります。Cloud ConnectorのHAはインフラストラクチャレベルの可用性を提供しますが、アプリケーションリクエストレベルでの透過的なセッションフェイルオーバーは提供しません。

Q: Cloud Connector をダウンタイムなしでアップグレードするにはどうすればよいですか？

ゼロダウンタイムのHAアップグレード手順を使用します。(1) マスターがトラフィックを処理し続けている間に、まずシャドウをアップグレードします。(2) 管理UIでロールを切り替え、シャドウを新しいマスターにします。(3) 以前のマスター（現在はシャドウ）をアップグレードします。各ステップは、次に進む前に検証できます。開始する前に、設定をエクスポートし、OSスナップショットを取得してください。この手順は、SAP Knowledge Base Article 3043130に文書化されています。

概要#

Cloud Connectorは、SAP BTPアプリケーションをRFCおよびHTTP経由でオンプレミスのバックエンドに接続するための実績あるソリューションです。そのリバースインボークトンネルモデルにより、インバウンドファイアウォールの要件が不要となり、アクセス制御の許可リストは明示的なデフォルト拒否のセキュリティ体制を強制します。オンプレミス統合要件のあるプロジェクトでは、専用のDMZホスト、マスター・シャドウのHAペア、デフォルト認証情報の変更、レビュー済みの許可リスト、計画的な12ヶ月のアップグレードサイクルが必須条件です。 Cloud Connectorのドキュメントでは完全な設定リファレンスを網羅しており、セキュリティ強化については Cloud Connector Securityを参照してください。このコネクタのシンプルさ（データベース不要、単一の送信ポート、フラットファイルシステム構成）は運用面での強みですが、規律あるバックアップと監視のプラクティスが求められます。アクセス制御モデルは要件定義段階で正しく設定してください。本番稼働後の後付けはコストがかかり、混乱を招きます。

次に読むべきもの#