3 認証と認可

MAのセキュリティと認可のモデルは、通信セキュリティ(機密性および整合性)と認可(認証および権限)がどのように構成され実装されるかを宣言し、定義します。

すべてのセキュリティおよび認可の構成とサービスは、MAベースのサーバーに共通です。これらのサーバーは、コマンドと制御、監視、データ転送、およびMAの情報サービス・インタフェースへのアクセスを認証、認可および保護します。

MAは、サービス対応アプリケーションを構築するためのモデルとインフラストラクチャを定義します。このモデルは一般化されたモデルではありません。グローバルのクラウドベース・デプロイメント環境で作動し、その環境に統合する必要がある、現在および将来のOracle GoldenGate製品を対象とするモデルです。Oracle GoldenGateサーバー・プログラムはMA インフラストラクチャを使用して実装されます。MAによって提供されるすべてのセキュリティおよび構成の実装は、共通のサービスです。

認証
アイデンティティ認証を使用する方法を学習します。
認可
認可モードを使用する方法を学習します。
WebSocketの認可
WebSocket認可を使用する方法を学習します。
エラー・コード
MA HTTPエラー・コードを確認します。
クロスサイト・リクエスト・フォージェリ
クライアント側の攻撃を回避する方法を学習します。

親トピック: マイクロサービス・アーキテクチャの保護

3.1 認証

アイデンティティ認証を使用する方法を学習します。

アイデンティティ認証設計の目標は、ユーザー、MAサーバーまたはアプリケーション、およびMAサーバーの間でアイデンティティ認証を確立することです。認証設計は、証明書の有効性またはユーザー資格証明(ユーザー名とパスフレーズのペア)の有効性に依存します。

MAサーバーはRESTサービス・インタフェースを公開し、ユーザーとアプリケーションはこれを使用して、1つまたは複数のMAデプロイメントでの操作の制御、サービス管理、ステータスとパフォーマンスの監視など、サービスをリクエストできます。次の図で、ユーザー、アプリケーション、サーバーおよびデータベースの関係を説明しています。

ユーザー、アプリケーション、サーバーおよびデータベースの関係

認証には次のタイプの証明書が使用されます。

アプリケーション証明書: アプリケーション証明書は特定のアプリケーションに発行される証明書です。アプリケーション証明書はそのアプリケーションによって格納されます。Oracle GoldenGateクライアント・アプリケーションは、アプリケーション構成によって指定されたアプリケーションのOracle Walletにアプリケーション証明書を格納します。アプリケーションのOracle Walletのデフォルトの場所は$OGG_SSL_HOMEディレクトリ内です。
ユーザー証明書: ユーザー証明書は特定のユーザーに発行される証明書です。Oracle GoldenGateクライアント・アプリケーションは、ユーザーのOracle Walletにユーザー証明書を格納します。ユーザーのOracle Walletのデフォルトの場所はユーザーのホーム・ディレクトリ内です。ユーザー証明書と一緒に発行されるサービス・リクエストには、ホスト環境から取得されるユーザー名とグループ情報が含まれます。この情報によって、アプリケーションを実行する実際のユーザーが識別されます。
サーバー証明書: サーバー証明書は特定のMAサーバーに発行される証明書です。サーバー証明書は、MAサーバーによってサーバーのOracle Walletに格納されます。サーバーのOracle Walletのデフォルトの場所はサーバーのインストール・ディレクトリ内です。MAサーバーは、サーバー証明書に記述されたアイデンティティとしてアプリケーションに認証されます。

ユーザーまたはアプリケーションのデータベース認証: MAサーバーがサポートするサービス・インタフェース・リクエストを満たすには、ソース・データベースまたはターゲット・データベースにログインする必要があります。MAサーバーのデータベース・アクションは、サービス・リクエストの要件を満たすために必要な特定の操作に限られます。次の表では、MAによってサポートされる認証のタイプを説明します。

認証のタイプ

説明

MAサーバーのデータベース認証

この構成では、MAサーバーが、自らの資格証明を唯一の認証済ユーザーとして使用してデータベースとの接続を確立するように設定されます。データベース・アクセスを必要とするすべてのサービス・リクエストは、MAサーバー・データベース・セッションを使用します。データベースの操作はMAから発生しているとしてロギングされます

MAサーバーのデータベース認証(データベース・プロキシ・サポートあり)

このタイプでは、MAサーバーが、自らの資格証明を使用してデータベースとの接続を確立するが、MAサーバー認証済接続を介してプロキシ・ユーザー・セッションをサポートするように設定されます。プロキシ・サポートはユーザー名または識別名を使用して構成されます。

パススルー・データベース認証

この構成は、MAサーバーが、クライアント提供のユーザー名とパスワードを使用してデータベースとのセッションまたは接続を確立するように構成されます。

ユーザーエイリアス・データベース認証

この構成では、MAサーバーが、クライアント提供のエイリアスIDを使用してデータベースとのセッションまたは接続を確立するように構成されます。エイリアスIDは資格証明にマッピングされ、データベースとのセッションまたは接続を確立するためにMAサーバーによって保持されています。

Oracle UTL_HTTP認証

ユーザーとアプリケーションの認証モデルは、RESTサーバー・インタフェース・リクエストのMAサーバーへの発行をサポートするデータベース・パッケージにも適用されます。MAサーバーのセキュリティ構成によっては、UTL_HTTP Oracle Databaseパッケージを使用するパッケージまたはプロシージャでは、UTL_HTTPでの認証のためのクライアント側証明書を使用できるようにクライアント・データベース・セキュリティ環境を構成する必要があります。

UTL_HTTPでクライアント側の証明書を使用するには、次のようにします。

データベース・クライアントのOracle Walletを構成します。ウォレットの作成とマスター・キーの追加を参照してください。
クライアント側の認証にTLS (SSL)を使用してUTL_HTTPを構成します。UTL_HTTPの使用を参照してください。

証明書失効リスト認証のサポート

MAサーバーは、認証プロセスの一部として証明書失効リスト(CRL)のチェックをサポートしています。MAサーバーは更新されたCRLの自動的な問合せを行いませんが、MAインフラストラクチャは実行時のサーバーCRL情報の更新をサポートしているため、MAサーバーを再起動する必要はありません。TLS証明書失効リストの処理を参照してください。

親トピック: 認証と認可

3.2 認可

認可モードを使用する方法を学習します。

セキュリティ認証モード

サポートされるセキュリティ認証モードのリストを次に示します(セキュリティ認証モードによって認可情報を示すエンティティの認証性が確立されます)。ここでは/config/securityDetails/network/common/authModeセキュリティ設定に使用できる値を示しています。このモードが設定されるのはOracle GoldenGate MAデプロイメントを構成するときです。

認可モードID ノート

server_only サーバー証明書のみを検証します。サーバー証明書が必須です。クライアント証明書は無視されます。

client_server クライアント証明書とサーバー証明書の両方を検証します。両方の証明書が必須です。

clientOptional_server これはデフォルトです。クライアント証明書がある場合に検証します(オプションであるため)。サーバー証明書を検証します(これは必須です)。

ユーザー権限

これらのユーザーのセキュリティ・ロールは、管理サーバーから構成できます。セキュアまたは非セキュア・デプロイメントの設定を参照してください。

ロールID

権限レベル

ユーザー

情報のみのサービス要求を許可します。これは、MAのいずれに対しても操作を変更したり、操作に影響を与えたりすることはありません。問合せ/読取り専用情報の例には、パフォーマンス・メトリック情報およびリソースのステータスと監視情報が含まれます。

オペレータ

ユーザーは、リソースの開始および停止などの操作アクションのみを実行できます。オペレータは、MAサーバーの操作パラメータまたはプロファイルを変更することはできません。

管理者

全面的なアクセス権がユーザーに与えられ、セキュリティに関連しない一般的なサーバーの操作パラメータおよびプロファイルを変更することもできます。

セキュリティ

セキュリティ関連オブジェクトの管理権限を付与し、セキュリティ関連のサービス・リクエストを呼び出します。このロールにはすべての権限があります。

注意:

これらは認可権限であり、認証とは直接関連していません。

親トピック: 認証と認可

3.3 WebSocketの認可

WebSocket認可を使用する方法を学習します。

REST APIコールは、標準のHTTPリクエストを使用して行われ、RFC2616で説明されている認可メカニズムを利用します。WebSocketプロトコル(RFC6455)は、ストリーミングのようなインタフェースであり、許可を必要とせず、特別な処理が必要なため、異なりますWebSocketは標準のHTTP認可メカニズムを使用して管理できます。

ネイティブHTTP認可

ネイティブHTTP認可では、初期WebSocket確立要求にヘッダーが含まれています。MAサーバーは、認可ヘッダーをチェックして、要求側ユーザーに関連付けられたロールがWebSocket確立要求に割り当てられたロール以上であるかどうかに基づいて要求を承認または拒否します。

例3-1の例

GET /chat HTTP/1.1
Host: myserver.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://myserver.com
Sec-WebSocket-Protocol: ogg
Sec-WebSocket-Version: 13
Authentication: Basic xgfDE24sDwrasdbliop875ty=

親トピック: 認証と認可

3.4 エラー・コード

MA HTTPエラー・コードを確認します。

MA HTTP認証および認可エラー・コードのいくつかは次のとおりです。

401 未認可

提示された資格証明が不正な形式であるか、必要なときに欠落しているすべての場合に返されます。認可資格証明の一部として提示された場合は、スペルが正しくないか、登録解除されたユーザー名が含まれています。認可リソース(404エラー)には適用されません。

403 禁止

提示された資格証明が整形式であるが、無効であるか、または基礎となるリソースへのアクセス権を付与するための十分な権限を持っていないすべての場合に返されます。

404 見つかりません

提示された資格証明が整形式であるが、サーバー側リソースが見つからない場合に返されます。

たとえば、/services/v2/authorizations/all/jamesを使用してユーザー情報を取得しようとしたときに、ユーザーjamesが登録済ユーザーではない場合です。適切な登録がなければjamesリソースが存在しないため、このエラー・コードが返されます。

完全なリストは、Internet Engineering Task Force RFC 7231標準の次の場所にあります。

https://tools.ietf.org/html/rfc7231

親トピック: 認証と認可

3.5 クロスサイト・リクエスト・フォージェリ

クライアント側攻撃を回避する方法を学習します。

クロス・サイト・リクエスト・フォージェリ(CSRF)は、悪意があったり認可されていないWebサイトで、クライアント・ブラウザが有効なユーザーまたはクライアント認証オブジェクトを使用して、保護されたサーバー側リソースへの危険性の高いアクションまたはリクエストを実行または発行させようとするクライアント側攻撃です。攻撃は、攻撃されたWebサイトによって公開されたアクションとリソースに制限されます。

攻撃のモード

一般的な攻撃のモードは、悪質なエージェントがユーザーのブラウザを悪意のあるWebサイトにリダイレクトさせることです。この悪意のあるサイトの悪意のあるリソースが原因で、ユーザーのブラウザがクライアント側スクリプト(JavaScript)をダウンロードすることになります。このダウンロードが原因で、ユーザーが前に認可を取得した保護されたWebサイトに対してユーザーのブラウザが危険性の高いリクエストを発行することになります。ブラウザは、悪質なスクリプトのリクエスト・ペイロードと、リクエストとともに自動的に伝達されるすべての認可Cookieの両方を提供する、危険性の高いリクエストを発行します。

たとえば、悪意のあるWebサイトのスクリプトは、ユーザーのブラウザに対して、高いセキュリティ・クリアランスを持つ新しいユーザーの追加を要求するように指示します。リクエストは、現在のブラウザ・ユーザーの現在の認可Cookieとともに、保護されたWebサイトに発行されます。このCookieは、悪意のあるリクエストに対して自動的かつ透過的に配信されます。有効なユーザー許可を持つリクエストは、別のリダイレクトされた悪意のあるサイトから取得されるスクリプトによって偽造され、現在のブラウザ・ユーザーの認可コンテキストで悪意のあるリクエストを発行します。

防御措置をとる

CSRFの脅威に対応したブラウザは、クロスサイト情報が制限され、要求元のブラウザ環境に関する追加の情報が含まれるような仕組みを実装しています。

スクリプトのリクエストがターゲットとしている以外のサイトから取得したスクリプトを実行すると、ブラウザは次の許可されたメソッドのみを明示的に定義できます。

GET
HEAD
POST

ブラウザによって自動的に設定されるHTTPヘッダー以外に、明示的に設定できるHTTPヘッダーは、CORS-safelisted request-header (単純ヘッダー)のみです。

Accept
Accept-Language
Content-Language
Content-Type
Last-Event-ID
DPR
Save-Data
Viewport-Width
Width

Content-Typeヘッダーは、次のもののみを宣言できます

application/x-www-form-urlencoded
multipart/form-data
text/plain

イベント・リスナーは、XMLHttpRequestUploadオブジェクトに登録することができず、リクエストで許可または使用されるReadableStreamインスタンスでもありません

CSRF緩和戦略

スクリプトから発行されたリクエストは、現在のターゲット・リクエストに次の1つ以上が含まれているため、同じサイトから再試行されません。

Origin HTTPヘッダー: 常にクロスサイト・スクリプト・リクエストに含まれています。

Referer HTTPヘッダー: リクエストが参照された親ページからのものである場合に含まれます。(リモート・ファンクション・コールでRefererのスペルが間違っていることに注意してください)。

プロキシまたはリバース・プロキシが要求元のクライアントとターゲットWebサイトの間にある場合、プロキシまたはリバース・プロキシは、次の拡張HTTPヘッダーを含むように構成する必要があります。

X-Forwarded-Host - リクエストの対象となった元のホスト名(プロキシ・ホストまたはリバース・プロキシ・ホスト)。X-Forwarded-Hostは、伝播されたリクエストのOriginヘッダーを置き換える必要がありますが、同じ情報を含んでいます。

X-Forwarded-Server - プロキシまたはリバース・プロキシ・サーバーのホスト名。

評価順の戦略は次のとおりです。

Origin HTTPヘッダーが存在する場合は、Originホスト名が元のサーバーのホスト名と一致することを確認します。
Referer HTTPヘッダーが存在する場合は、Origin HTTPヘッダーも存在し、OriginとReferer HTTPヘッダーの両方のホスト名値が一致することを確認します。
X-Forwarded-Host HTTPヘッダーが存在する場合は、X-Forwarded-Server HTTPヘッダーも存在し、X-Forwarded-HostとX-Forwarded-Server HTTPヘッダーの両方のホスト名の値が一致することを確認します。
OriginヘッダーもX-Forwarded-Host HTTPヘッダーも存在しない場合、リクエストはクロス・サイト・リクエストとして発信されていないものと推定されます。これにより、クロス・サイト・スクリプティング(XSS)ポリシーをサポートするためのブラウザの準拠が保証されます。

注意:
クライアントのXSSポリシーサポートに依存しているため、一般的な非ブラウザ・クライアント(cURL、Wget、Python、Perl、eNetcatなど)からの悪意のあるCSRFリクエストは保護できません。

親トピック: 認証と認可