SAP CPIのセキュリティアーティファクト基礎：証明書・資格情報・キーストアの管理

SAP CPI（Cloud Integration）では、外部システムとの通信に使う秘密情報をiFlowへ直接記述せず、セキュリティアーティファクトとして分離して管理します。代表例は、ユーザー資格情報、OAuth 2.0関連情報、キーペア、証明書、キーストア、PGP鍵です。iFlowの設計と認証情報の管理を分けることで、接続先の変更や資格情報の更新を安全に進められます。

この記事では、アーティファクトの選び方、登録時の確認項目、デプロイ後の接続テスト、期限切れや権限エラーの切り分けを、運用担当者が使える形でまとめます。iFlow全体の構成を先に確認したい場合は、SAP CPI iFlowの基礎も参照してください。

01セキュリティアーティファクトの役割

セキュリティアーティファクトは、接続先が要求する認証方式に合わせて選択します。HTTP接続でユーザー名とパスワードを使う場合はユーザー資格情報、OAuth 2.0ではクライアント情報やトークン取得に必要な設定、SFTPの公開鍵認証ではキーペアやKnown Hosts、TLS相互認証ではクライアント証明書を含むキーストアを使います。

アーティファクト名は接続先、用途、環境を識別できる規則にします。たとえば S4P_HTTP_PROD_BASIC や SFTP_PARTNERA_CLIENTCERT のように、システム名と用途を含めると、iFlowから参照する際の誤選択を減らせます。

02登録前に整理する認証要件

登録作業の前に、接続先が要求する認証方式と通信方向を確定します。送信側がSAP CPIで、受信側が証明書を検証するのか、SAP CPIが受信側としてクライアント証明書を要求するのかで、必要な鍵や証明書が変わります。

次の項目を接続先の担当者と確認します。

• 通信プロトコルとポート番号
• 認証方式と必要なヘッダー
• 証明書または公開鍵の登録先
• TLSで検証するサーバー証明書の発行者
• 秘密鍵、パスワード、Client Secretの受け渡し方法
• OAuth 2.0のトークンURL、スコープ、認証方式
• SFTPのKnown Hosts、暗号アルゴリズム、ユーザー名
• PGPで使用する暗号化鍵と署名鍵の所有者
• 本番・テスト環境ごとのアーティファクト名

接続先の証明書チェーンを受け取った場合は、ルート証明書、中間証明書、サーバー証明書の関係を確認します。Subjectだけで判断せず、SANに接続先ホスト名が含まれること、有効期限が残っていること、用途が通信条件に合っていることを確認します。

03ユーザー資格情報を安全に使う手順

Basic認証やパスワード方式のSFTPでは、ユーザー資格情報アーティファクトに接続用のユーザー名とパスワードを登録します。iFlow側では、アダプターの認証設定からアーティファクト名を参照し、パスワードをメッセージ本文、ヘッダー、スクリプトへ記述しません。

運用手順は次の順序にします。

1. 接続先ごとに専用のサービスユーザーを用意する。
2. 接続先で必要最小限の権限を付与する。
3. SAP CPIのセキュリティアーティファクトに資格情報を登録する。
4. iFlowのアダプターで参照名を設定する。
5. デプロイ後、テスト用メッセージで接続を確認する。
6. 成功ログにパスワードやAuthorizationヘッダーが出力されていないことを確認する。

パスワード更新では、接続先側の変更、SAP CPI側のアーティファクト更新、iFlowの再デプロイまたは再起動要否、疎通テストの順に記録します。資格情報を複数のiFlowで共有する場合は、更新時の影響範囲を一覧化してから変更します。

04証明書とキーストアを管理する手順

TLS通信では、サーバー証明書を検証するだけの構成と、クライアント証明書を提示する相互TLS構成を分けて考えます。相互TLSでは、秘密鍵とクライアント証明書を含むキーペアに加えて、必要な証明書チェーンを登録します。

登録時は次の情報を台帳に残します。

• アーティファクト名と用途
• 証明書のSubject、Issuer、SAN
• 有効期限と更新予定日
• 秘密鍵の所有者と保管責任者
• 接続先へ登録した公開証明書
• 使用するiFlowとアダプター
• 更新手順、検証手順、切り戻し手順

証明書更新は、旧証明書の有効期間内に新証明書を登録し、接続先とSAP CPIの両方で切り替え可能な時間帯を確保して実施します。切り替え後は、正常系だけでなく、証明書検証、署名、暗号化、受信ファイル処理など、実際に証明書を使う処理を確認します。

SFTPでは、公開鍵認証用の秘密鍵と、接続先サーバーを検証するKnown Hostsを別の管理対象として扱います。公開鍵を接続先へ登録した後、ホスト鍵のフィンガープリントを照合してから接続テストを行います。SFTPアダプターの選択肢を比較する場合は、SAP CPIアダプター種別の比較が参考になります。

05OAuthとPGPの運用ポイント

OAuth 2.0では、Client ID、Client Secret、トークンURL、スコープ、認証方式を一つの接続要件として管理します。アクセストークンの取得に成功しても、業務APIのスコープやロールが不足していればAPI呼び出しは失敗します。HTTPステータスだけでなく、トークン取得と業務API呼び出しを分けて確認します。

PGPでは、暗号化に使う公開鍵と、復号・署名に使う秘密鍵の管理責任を明確にします。送信側が受信側の公開鍵で暗号化し、受信側が自分の秘密鍵で復号する流れを文書化します。鍵交換時にはKey ID、フィンガープリント、有効期限を照合し、鍵更新時は旧鍵で処理された未処理ファイルの扱いも決めておきます。

メッセージマッピングや変換処理と認証情報の変更を同じリリースに含めると、障害原因の切り分けが難しくなります。認証アーティファクトの変更と変換ロジックの変更は、可能な限り別の変更単位に分けます。変換設計との関係は、SAP CPIメッセージマッピングの基礎で整理できます。

06認証エラーを切り分ける方法

認証エラーが発生したら、まず失敗地点を特定します。接続先へのTCP/TLS接続、TLS証明書検証、認証情報の送信、トークン取得、業務API認可、メッセージ処理のどこで失敗したかを分けると、確認対象が絞れます。

監視では、メッセージ処理ログ、アーティファクトの更新履歴、接続先の監査ログを同じ時刻で照合します。エラー本文へ秘密情報をコピーせず、必要な場合はマスキングした識別子、Key ID、証明書のSubjectなどで調査します。運用監視の整理には、SAP CPIの監視とエラーハンドリングも利用できます。

07変更管理と定期点検

セキュリティアーティファクトは、登録した時点で完了ではなく、期限と利用箇所を継続的に管理します。少なくとも月次で、証明書・鍵・Client Secretの期限、未使用アーティファクト、複数iFlowからの参照状況、接続先側の権限変更を確認します。

変更記録には、変更理由、承認者、実施者、対象アーティファクト、影響するiFlow、実施時刻、テスト結果、切り戻し方法を含めます。秘密鍵やパスワードそのものをチケットや共有フォルダーへ保存せず、保管場所の参照情報だけを記録します。

本番障害を減らすには、期限通知を担当者個人の記憶に依存させず、台帳と監視で管理します。更新前には接続先の切り替え条件を確認し、更新後には送信・受信・再送の各シナリオを実行します。PI、PO、CPIの位置付けを含めた全体像は、SAP連携（PI/PO/CPI）の概要から確認できます。

08実務で使える確認チェックリスト

• 接続先の認証方式と通信方向を確定した
• アーティファクト名に環境と用途を含めた
• 秘密情報をiFlow、スクリプト、ログへ記述していない
• 証明書のSubject、SAN、Issuer、有効期限を確認した
• 公開鍵、秘密鍵、Known Hostsの役割を分離した
• OAuthのトークンURL、スコープ、API権限を確認した
• PGPのKey IDとフィンガープリントを照合した
• 更新前後の疎通テストと切り戻し手順を用意した
• 利用中のiFlow、所有者、期限を台帳に登録した
• エラーログに秘密情報が出力されていないことを確認した

認証方式を先に確定し、アーティファクトを用途別に分離し、期限と利用箇所を台帳で管理することが、SAP CPIのセキュリティ運用を安定させる基本です。