認証と認可

3 認証と認可

MAセキュリティでは、通信の認可と認証を定義します。認証には、資格証明ストアの構成や、AdminClientでのスクリプトの別名の構成などのタスクが含まれます。認可には、ネットワークおよびサーバーの構成のタスクが含まれます。

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

Oracle GoldenGate Microservicesでは、グローバルなクラウドベースのデプロイメント環境で運用しそれに統合するサービス対応アプリケーションの構築のためのインフラストラクチャを定義します。Oracle GoldenGateサーバー・プログラムは、マイクロサービス・インフラストラクチャを使用して実装されます。MAによって提供されるすべてのセキュリティおよび構成の実装は、共通のサービスです。

認証
アイデンティティ認証を使用する方法を学習します。
認可
認可モードを使用する方法を学習します。
WebSocketの認証と認可
WebSocketの認証および認可の使用方法について説明します。
レスポンス・ステータス・コード
MA HTTPS認証および承認エラー・コードの一部を次に示します。

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

3.1 認証

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

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

MAサーバーではRESTサービス・インタフェースを公開します。このインタフェースを使用することで、ユーザーとアプリケーションは1つ以上のMAデプロイメントでの操作の制御、サービス管理、ステータスとパフォーマンスの監視などのサービスをリクエストできます。

図ggcon_ap_001.pngの説明

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

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

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

認証のタイプ

説明

OS認証

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

データベース・プロキシがサポートされているOS認証

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

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

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

ユーザー別名データベース認証

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

例: クライアントとしてのOracle UTL_HTTPS認証の使用

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

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

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

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

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

親トピック: 認証と認可

3.2 認可

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

セキュリティ認証モード

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

『Oracle GoldenGate REST API』ガイドのサービス・プロパティの更新の関する項を参照してください。

認可モードID ノート

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

client_server これはデフォルトです。クライアント証明書とサーバー証明書の両方を検証します。両方の証明書が必須です。

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

ユーザー権限

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

ロールID

権限レベル

Security

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

Administrator

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

Operator

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

User

情報のみのサービス・リクエストを許可します。これは、どのMAの操作にも変更や影響がありません。問合せと読取り専用情報の例には、パフォーマンス・メトリック情報やリソースのステータス、監視情報などがあります。

ノート:

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

親トピック: 認証と認可

3.3 WebSocketの認証と認可

WebSocket認証と認可の使用方法について学習します。

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

ネイティブHTTPS認可

WebSocketハンドシェークはHTTPアップグレード・ヘッダーを使用して、HTTPプロトコルからWebSocketプロトコルに変更します。MAサーバーは、認可ヘッダーをチェックして、要求側ユーザーに関連付けられたロールがWebSocket確立要求に割り当てられたロール以上であるかどうかに基づいて要求を承認または拒否します。

例3-1

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

親トピック: 認証と認可

3.4 レスポンス・ステータス・コード

MA HTTPS認証および認可のエラー・コードの一部を次に示します。

次に示すレスポンス・ステータス・コードが使用されます。

1xx: Informal
2xx: Success
3xx: Redirect
4xx: Client Error
5xx: Server Error

4xxクライアントのレスポンス・ステータスは次のとおりです。

401 Unauthorized

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

403 Forbidden

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

404 Not Found

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

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

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

親トピック: 認証と認可