セキュリティ

セキュリティ・ガイドライン

次のベスト・プラクティスに従います:

アドインを使用可能な最新バージョンに更新します。
機密データを含むExcelドキュメントへのアクセスを制限します。
さらに露出するために、ワークブックにパスワードを追加することを検討してください。
常にHTTPではなくHTTPSエンドポイントを使用します。
基本認証を使用しないでください。
アドインをインストールするコンピュータに、Windowsの最新の更新プログラムとセキュリティ・パッチが適用されていることを確認します。
非推奨のトランスポート層プロトコル(SSL、TLS 1.0、TLS 1.1など)を無効にします。 Microsoftサポート・サイトの「KB5017811-2022年9月20日のデフォルト動作変更後のTransport Layer Security (TLS) 1.0および1.1の管理」を参照してください。
配布する前に、Excelのファイル・メニューのワークブックの検査機能を使用して、ワークブックの個人情報を確認および削除することを検討してください。文書インスペクタを使用する場合は、ワークシートの非表示チェック・ボックスが選択されていないことを確認します。アドインでは、非表示のワークシートを使用してワークブックをRESTサービスと統合するため、非表示のワークシートを削除しないでください。

Microsoftコンポーネント

Oracle Visual Builder Add-in for Excelは、多数のMicrosoftテクノロジに依存します。これらのMicrosoftテクノロジは、Microsoftプライバシ・ポリシーおよびその他のMicrosoft用語の対象となります。

このアドインをインストールして使用すると、これらのポリシーおよび条件、およびこれらのテクノロジの直接的または間接的な使用に同意することになります。「Microsoftプライバシに関するステートメント」を参照してください。

「ソフトウェアの依存関係」も参照してください。

認証オプション

ログイン時に、アドインはカタログ認証設定を使用してログイン方法を決定します。

アドインでは、5つの認証オプションがサポートされています:

デフォルト: ログイン時に、アドインはOracle Cloud Application anti-CSRFサーブレット・エンドポイントをpingします。 pingが成功した場合は、Oracle Fusion Applicationsトークン・リレーが使用されます。 pingが失敗した場合は、かわりにBasic認証が使用されます。
基本的なアクセス認証: 基本認証を参照してください。
Oracle Fusion Applicationsトークン・リレー: Oracle Fusion Applicationsトークン・リレー認証を参照してください。
OAuth 2.0認可コード(PKCE): PKCEを使用したOAuth 2.0 認可コード・フローを参照してください。
認証なし: 資格証明のプロンプトがありません。認証関連のヘッダーはリクエストに追加されません。

新しいカタログの作成時に認証メソッドを選択できます。後で変更することもできます。

認証設定の構成方法については、「RESTサービスの認証メソッドの設定」を参照してください。

Basic認証

Oracle Visual Builder Add-in for Excelは基本的な認証をサポートします。

基本アクセス認証を使用するようにカタログが構成されている場合、ビジネス・ユーザーは、最初のリクエストがそのカタログ・エンドポイントに送信される前に基本資格証明の入力を求められます。「認証オプション」を参照してください。
アドインによって、RESTリクエストの認可ヘッダーのユーザー資格証明がエンドポイントに送信されます。詳細については、RFC 7617を参照してください。
HTTPとともに使用する場合、基本認証はセキュアではありません。 Basic認証はHTTPSでのみ使用し、非本番環境でのみ使用することをお薦めします。
基本認証を使用した特定のサービスの有効な資格証明は、トークン・リレーの有効な資格証明と異なる場合があります。

Oracle Fusion Applicationsトークン・リレー認証

Oracle Visual Builder Add-in for Excelは、Oracle Fusion Applicationsトークン・リレー・サーブレットを使用するOracle Cloudアプリケーションによって公開されるRESTサービスの認証をサポートします。トークン・リレー認証メカニズムの技術的な詳細は、このトピックを参照してください。

アドインでは、埋込みwebブラウザ・コントロールを使用して、ワークブック・ユーザーとFusion Application (FA)認証プロバイダ間のログイン相互作用シーケンスをホストします。ログインに成功すると、アドインは必要な認証トークンを取得し、後続のRESTリクエストで使用します。特に、アクセス・トークンは、認可ヘッダーのBearer認証スキームを使用して送信されます。詳細は、RFC 6750を参照してください。

ログイン順序の動作

このアドインは、RESTサービスへのアクセスを必要とするビジネス・ユーザーによって開始されたビジネス操作の直前に認証プロセスを実行します。アドインでは、次のエンドポイントを使用して認証トークンを取得します:

UIホーム・ページ: たとえば、https://my-service-host/fscmUI/faces/FuseWelcomeです。
Anti-CSRFエンドポイント: たとえば、https://my-service-host/fscmRestApi/anticsrfです。
トークン・リレー・サーブレット・エンドポイント: 例: https://my-service-host/fscmRestApi/tokenrelay.

埋込みブラウザでログイン・シーケンスを開始

アドインには、埋込みブラウザ・コントロールを含むモーダル・ポップアップ・ログイン・ウィンドウが表示され、UIホーム・ページURLにナビゲートするようにブラウザ・コントロールに指示します。「組込みブラウザ」を参照してください。
ビジネス・ユーザーがまだ正常にログインしていないため、ブラウザはログイン・フォームのあるページにリダイレクトされます。このフォームには、通常、ユーザー名とパスワードのフィールドと送信ボタンが含まれます。
ログイン・ユーザー・インタフェース・ページは、FA環境によって制御されます。 SSO、マルチ・ファクタ認証など、複数のステップが関与する場合があります。
ユーザーがジェスチャまたはログイン・ページのロジックによってブラウザのページ・ナビゲーション・イベントが発生するたびに、アドイン・イベント・ハンドラに通知され、アドインによって認証テスト(「認証テスト」を参照)が実行され、ユーザーがログインしたかどうかが確認されます。
- ユーザーが正常にログインした場合、ログイン順序は完了です。アドインによってログイン・ウィンドウが自動的に閉じ、収集された認証トークンを使用してログイン・シーケンスをトリガーしたRESTリクエストを続行できます。
- ユーザーがまだログインしていない場合、ログイン・ウィンドウは表示されたままになり、アドインはページ・ナビゲーション・イベントをリスニングし続けます。
- 正常にログインする前にユーザーがログイン・ウィンドウを閉じると、認証プロセスを開始した操作は取り消されます。

認証テスト

埋込みブラウザでのページ遷移のアドイン・ウォッチで、ユーザーが正常にログインしたかどうかをテストします。埋込みブラウザからcookieを使用すると、アドインがトークン・リレー・サーブレットからトークンを取得できる場合、ユーザーは正常に認証されました。

テストの詳細:

各ページ・ナビゲーション・イベントがブラウザから呼び出されると、アドインは、アンチCSRFエンドポイントへのGETリクエストを実行して、アンチCSRFトークンの取得を試みます。このステップは、反CSRFトークンを取得するとスキップされます。
その後、アドインはトークン・リレー・サーブレット・エンドポイントにGETリクエストを行います。リクエストが拒否された場合、テストは失敗します。それ以外の場合は、200 OKでcontent-type application/jsonのレスポンス・ペイロードを使用します:
1. ペイロードが解析および検証されます。 token_typeメンバーには値JWTがあり、access_tokenメンバーが存在し、空でない必要があります。
2. access_tokenの値はメモリーに取得され、後続のRESTリクエストに使用されます。
3. 解析が成功した場合、テストは合格したとみなされます。ログイン・ウィンドウがクローズし、ターゲットのRESTリクエストが続行されます。
4. それ以外の場合、テストは失敗したとみなされ、ログイン・ウィンドウは開いたままになります。

バリエーション

統合ワークブックのサービス・カタログの認証メソッドが「デフォルト」として構成されている場合は、ログイン・シーケンスが開始される前に、アンチCSRFエンドポイントへの初期のpingリクエストが行われます。
1. リクエストが404などのエラーを返した場合、アドインはトークン・リレー認証メカニズムを放棄します。つまり、Basic認証の使用に戻ります。
2. リクエストがコンテンツ・タイプがapplication/jsonの200を戻し、ペイロードに空でないxsrftokenメンバーが含まれている場合、アドインはログイン・シーケンスに進みます。
統合ワークブックのサービス・カタログの認証メソッド・プロパティがOracle Fusionアプリケーション・トークン・リレーとして構成されている場合、アンチCSRFエンドポイントへの初期pingはスキップされます。 pingは、ページ・ナビゲーション中に後で行われます。

要件

UIホーム・ページは、ブラウザで認証されていないリクエストによってブラウザがリダイレクトされ、ログイン・ページにリダイレクトされてログイン・シーケンスが開始されるように保護する必要があります。
/anticsrfエンドポイントでは、匿名(未認証)アクセスを許可する必要があります。レスポンス・ペイロードには、xsrftokenメンバーのトークンが含まれている必要があります。
ブラウザ・ログイン・シーケンス中に発行されたcookieで識別される認証済ユーザーのみがアクセスできるように、/tokenrelayエンドポイントを保護する必要があります。レスポンス・ペイロードには、値"JWT"と、空でないaccess_tokenメンバーを持つ必要があるtoken_typeメンバーが含まれている必要があります。詳細については、RFC 7519を参照してください。
Oracle Fusion Applicationsトークン・リレーは、標準化されたペイロードを持つ標準化された/anticsrfおよび/tokenrelayエンドポイントを含むOracle Cloudアプリケーション・デプロイメントでのみサポートされます。この動作は現時点では構成できません。
トークン・リレーは、ORDSやVisual Builderビジネス・オブジェクト(VBBO)などの他のサービス・タイプではサポートされていません。

PKCEを使用したOAuth 2.0 認可コード・フロー

Oracle Visual Builder Add-in for Excelは、OAuth 2.0認可コード・フローとProof Key for Code Exchange (PKCE)を使用したRESTサービスの認証をサポートしています。この認証メソッドでは、アドインなどのクライアントは、サービス・エンドポイントへのRESTリクエストの作成に使用できるアクセス・トークンを認証および取得できます。

この認証メソッドは、「Visual Builderビジネス・オブジェクト」などの一部のサービスで必要です。

OAuthを構成する最も簡単な方法は、JSON構成ファイルに必要なOAuthプロパティを入力してインポートすることです。ワークブックにOAuthを構成するステップは、「カタログのOAuth 2.0認可の構成」を参照してください。

OAuth 2.0認可コード・フローを使用するようにワークブックを構成するには、RESTサービス所有者から認証の詳細を取得する必要があります。「OAuth 2.0認可プロパティ」を参照してください。

OAuth 2.0認可プロパティ

OAuth 2.0認可コード・フローを使用するようにワークブックを構成するには、使用しているサービスのセキュリティ管理者からクライアント識別子を取得する必要があります。必要なエンドポイントURLなど、その他の詳細も指定する必要があります。 RESTサービス所有者にお問い合せください。

必要なOAuthプロパティは次のとおりです:

クライアント識別子: 承認フローの実行時に使用するアドイン用に設定された識別子。この値は、サービスのセキュリティ管理者から取得します。
認可エンドポイント: ユーザー・エージェント・リダイレクションを介してリソース所有者から認可を取得するためにクライアントが使用する認可サーバー・エンドポイント。
リダイレクト・エンドポイント: リソース所有者user-agentを使用してクライアントに認可コードを含むレスポンスを返すために認可サーバーによって使用されるクライアント・エンドポイント。
アクセス・トークン・スコープ: 認可およびトークン・エンドポイントにより、クライアントは"scope"リクエスト・パラメータを使用してアクセス・リクエストのスコープを指定できます。
トークン・エンドポイント: クライアントがアクセス・トークンの許可付与を交換するために使用する許可サーバー・エンドポイント(通常はクライアント認証を使用)。

ノート:

アドインにはクライアント・シークレットは必要ありません。

これらのプロパティの詳細は、「OAuth 2.0認可フレームワーク」を参照してください。

OAuth 2.0認可コード・フローのステップ

承認フローは、次のステップに従います:

アドインは、OAuth2構成プロパティを検証してログイン順序を開始します。プロパティが有効な場合、フローは続行されます。
プロパティが欠落しているか無効である場合、ログイン試行は中止され、エラーが報告されます。たとえば、絶対URLではないエンドポイント・プロパティは無効で、ログインが中断されます。
アドインは、認可エンドポイント・プロパティを使用してUniform Resource Identifier (URI)を構成し、クライアントIDおよび「OAuth 2.0認証コード(PKCE)」画面に保存されているその他の値を構成します。
アドインにはログイン・ブラウザ・ウィンドウが表示され、ブラウザにその認可Uriに移動するように指示します。「組込みブラウザ」を参照してください。
ブラウザでのページの遷移およびリダイレクトのためのアドイン・ウォッチ。他のすべてのブラウザおよびユーザー対話は、認可サーバーのロジックおよび構成によって管理されます。
ユーザーが資格証明を提供したり同意を得るために、複数のページおよびステップが必要になる場合があります。
認可サーバーがブラウザをリダイレクト・エンドポイントに戻すと、アドインはブラウザを閉じます。
リダイレクトにエラーが示されている場合、アドインはエラーを報告し、ログイン・フローを中止します。リダイレクトに成功すると、アドインは返された値に対して検証を実行します。これが成功すると、アドインはフローを続行します。
リダイレクトが成功すると、アドインは認可コードを収集し、他のキー値とともにトークン・エンドポイントへのPOSTリクエストで送信します。
トークン・エンドポイントは、後続のRESTリクエストを行うときに、Bearerスキームを使用して承認ヘッダーにアドインが含まれるアクセス・トークンを返します。

認証コード・フローの詳細は、「許可コード権限付与」を参照してください。 PKCEの詳細は、「OAuthパブリック・クライアントによるコード交換の証明キー」も参照してください。

カタログのOAuth 2.0認可の構成

OAuth 2.0認可コード・フローを使用して、RESTサービスで認証するように統合ワークブックを構成できます。レイアウトの作成時にカタログを作成するときに、必要な認証プロパティを指定できます。

ビジネス・オブジェクト・カタログ・エディタから、この認証メソッドを使用するように既存のカタログを構成することもできます。

この認証メソッドを構成する最も簡単なメソッドは、Oracle Visual Builder Add-in for Excelから空白のJSONファイルをエクスポートし、必要な値を入力して、完了した構成ファイルをインポートすることです。

続行する前に、RESTサービス所有者から必要なプロパティを取得します。「OAuth 2.0認可プロパティ」を参照してください。

新規レイアウトの作成時に構成ファイルをインポートするには:

Excelワークブックでの表レイアウトの作成またはExcelワークブックでのフォーム表レイアウトの作成の説明に従って、新規レイアウト設定ウィザードを起動します。
ウィザードの最初の画面で、「認証」リストから"OAuth 2.0認可コード(PKCE)"を選択し、「次」をクリックします。

ウィザードに、OAuth 2.0プロパティを入力するための画面が表示されます。この図は、画面のフィールドにサンプル値がある画面を示しています。

図oauth-properties-screen.pngの説明

ノート:
「ビジネス・オブジェクト・カタログ・エディタ」の「上級」ページから、既存のカタログのこの画面にアクセスすることもできます。この画面を開くには、「認証」リストから"OAuth 2.0認可コード(PKCE)"を選択し、「認証フローのプロパティの編集」をクリックします。「RESTサービスの認証メソッドの設定」を参照してください。
「エクスポート」アイコン()をクリックして、必要なプロパティを含む空白のJSONファイルをローカル・ドライブに保存します。

このファイルをサービス所有者に提供して入力してください。

次に、サンプル値を示すJSONファイルの例を示します:

{  
  "type": "oauth2",
  "authorizationCode":
  {
    "clientId": "31415926",
    "authorizationEndpoint": "https://demo/oauth2/v1/authorize",
    "redirectionEndpoint": "https://demo/authorization-redirect",
    "accessTokenScope": "scope1 scope2",
    "tokenEndpoint": "https://demo/oauth2/v1/token"
  }
}

必要な値でJSONファイルを取得したら、「インポート」アイコン()をクリックしてファイルをアドインにインポートします。
「次」をクリックして、新規レイアウト設定ウィザードを続行します。

OAuth制限事項および既知の問題

統合ワークブックのカタログにOAuth 2.0を構成する前に、次の制限事項を確認してください:

PKCEのサポートが必要です。 RFC 7636を参照してください。
現在、トークン・リフレッシュ・ロジックはサポートされていません。
OAuth2フローの最初のステップでは、code_challengeは code_challenge_method=S256を使用して設定されます。「プレーン」はサポートされていません。

サービス認可およびユーザー権限

RESTサービスでは、認証("who am I")に加えて、多くの場合、すべてのサービス・リクエスト(GET、POST、PATCHなど)で認可("what am I allowed to do")が強制されます。 RESTサービスでは、データを表示および更新するために、ビジネス・ユーザーに特定の権限が必要になる場合があります。

Oracle Visual Builder Add-in for Excelは、ユーザー・アイデンティティまたは任意の種類のprivilege/role/authorization情報にアクセスできず、操作の前に認可を確認できません。代わりに、現在のユーザーがリクエストされた操作を実行する権限がない場合に、承認を強制し、エラーを返すサービスです。

ビジネス・ユーザーが認可されていない操作を許可するようにワークブックが構成されている場合、ユーザーには403 Forbiddenエラーなどのエラーが表示されることがあります。このような場合は、ビジネス・ユーザーに適切な権限を付与するために、RESTサービス所有者またはシステム管理者をフォローアップする必要があります。

Transport Layer Security

アドインがHTTPSを使用してRESTエンドポイントに接続する場合、アドインはシステム・デフォルトのTransport Layer Security (TLS)動作に依存して、使用するTLSプロトコルを決定します。

アドインはExcelプロセス内で実行されるため、これを行うために.NET Frameworkの4.8デフォルト設定に完全に依存することはできません。システムのデフォルト動作が有効になるように、アドインは現在のアプリケーション・ドメインのAppContext.DontEnableSystemDefaultTlsVersionsプロパティをfalseに設定します。

次のMicrosoftドキュメントを参照してください:

デジタル証明書

Oracle Visual Builder Add-in for Excelを構成するアーティファクトは、デジタル証明書を使用して署名されます。デジタル・シグネチャは、これらのアーティファクトの真正性を証明し、パブリッシャのOracleのアイデンティティを検証します。デジタル・シグネチャは、信頼できる認証局から発行された証明書を使用して作成されます。

証明書は、製品ビルド・プロセス中にアーティファクトに署名するために使用されます。すべての署名可能アーティファクトは、インストーラ(MSI)ファイルから始まり、アドインを構成するすべてのDLLを含めて署名されます。

ノート:

このトピックでは、Windowsエクスプローラで証明書を表示およびインストールし、証明書公開キーをコピーする手順について説明します。 Windowsのエディションとバージョンによって、ステップが異なる場合があります。詳細は、使用しているバージョンのWindowsのドキュメントを参照してください。

証明書を検査できますか。

インストールの前後にこれらの証明書を検査して、アドイン・アーティファクトの信頼性を検証できます。

これを行うには、インストーラ・ファイル(すべてのユーザー・インストーラの場合はvbafe-installer-all-users.msi)に移動し、プロパティ・ウィンドウを開き、「デジタル・シグネチャ」タブを選択します。

注意:

インストーラで「デジタル・シグネチャ」タブがない場合は、ファイルを破棄します。信頼できない可能性があります。

失効したシグネチャ

期限切れの証明書は、シグネチャが無効であるという意味ではありません。適切にタイムスタンプされたシグネチャは、証明書に表示される「有効な開始/終了」日付範囲のあとでも有効のままです。

最新の証明書を取得するには、最新の使用可能なバージョンのアドインにアップグレードします。

信頼できる出版社

Microsoft Excelには、「信頼できるパブリッシャによるアプリケーション・アド・インの署名が必要」というオプションの信頼センター設定が用意されています。

この機能を使用するには、証明書をインストールします:

「デジタル・シグネチャ」タブで、シグネチャ・リストからシグネチャを選択し、「詳細」をクリックします。
「デジタル・シグネチャ詳細」ダイアログで、一般タブを選択し、「証明書の表示」をクリックします。
証明書ダイアログの一般タブで、「証明書のインストール...」をクリックします。
証明書インポート・ウィザードで、すべてのユーザー・インストーラの場合は「ローカル・マシン」、現在のユーザー・インストーラの場合は「現在のユーザー」のいずれかを選択します。
「次へ」をクリックします。
「すべての証明書を次のストアに配置」を選択し、「ブラウズ」をクリックします。
「証明書ストアの選択」ダイアログで、「信頼できるパブリッシャ」を選択し、OKをクリックします。
「次」、「終了」の順にクリックしてウィザードを閉じます。

証明書がExcel Trust Centerに表示されます。

詳細は、Microsoftドキュメントを参照してください。

公開キー

アドイン・デジタル証明書に関連付けられた公開キーのコピーを取得するには:

「デジタル・シグネチャ」タブで、シグネチャ・リストからシグネチャを選択し、「詳細」をクリックします。
「デジタル・シグネチャ詳細」ダイアログで、一般タブを選択し、「証明書の表示」をクリックします。
証明書ダイアログで、詳細タブを選択し、リストから公開キーを選択します。
「ファイルにコピー...」をクリックします。
証明書のエクスポート・ウィザードの手順に従います。

アドイン証明書更新サイクル

Oracleは約2年ごとに新しいデジタル証明書を取得します。利用可能なら、それ以降のアドインのリリースは新しい証明書で署名されます。

証明書と公開キーを以前にインストールした場合は、新しい証明書で署名された新しいバージョンのアドインにアップグレードしたあとに、そのプロセスを繰り返す必要があることがあります。