6 セキュリティ
RESTのためのSODAなどのORDSでは、サービスを保護するためにロールベースのアクセス制御が使用されます。ここでは、RESTのためのSODAに必要なロールおよび権限について説明しています。
この項を読む前に、ORDSのセキュリティ機能に精通している必要があります。
REST SODAを使用する前に、データベース・ロールSODA_APP
をデータベース・ユーザーに付与する必要があります。さらに、ords.enable_schema
を使用してORDSでデータベース・スキーマ(ユーザー・アカウント)を有効にする際に、アプリケーション・サーバー・ロールSODA Developer
を持つユーザーのみがサービスにアクセスできるように、権限が作成されます。具体的には、ords.enable_schema
は次の権限マッピングを作成します。
exec ords.create_role('SODA Developer');
exec ords.create_privilege(p_name => 'oracle.soda.privilege.developer',
p_role_name => 'SODA Developer');
exec ords.create_privilege_mapping('oracle.soda.privilege.developer', '/soda/*');
このことは、デフォルトで、JSONドキュメント・ストアにアクセスするにはユーザーはアプリケーション・サーバー・ロールSODA Developer
を持っている必要があることに影響します。
カスタムの権限マッピングを追加することもできます。次に例を示します。
declare
l_patterns owa.vc_arr;
begin
l_patterns(1) := '/soda/latest/employee';
l_patterns(2) := '/soda/latest/employee/*';
ords.create_role('EmployeeRole');
ords.create_privilege(p_name => 'EmployeePrivilege',
p_role_name => 'EmployeeRole');
ords.create_privilege_mapping(p_privilege_name => 'EmployeePrivilege',
p_patterns => l_patterns);
commit;
end;
この例では、EmployeeRole
ロールを持つユーザーのみがemployee
コレクションにアクセスできるように指定する権限マッピングを作成します。
複数の権限パターンが同じリソースに適用された場合、最も具体的なパターンを持つ権限が他の権限よりも優先されます。たとえば、パターン/soda/latest/employees/*
および/soda/*
は、どちらもリクエストURL http://example.org/ords/quine/soda/latest/employee/id1
と一致します。
'/soda/latest/employees/*'
は'/soda/*'
よりも具体的であるため、EmployeePrivilege
権限のみがこのリクエストに適用されます。
注意:
SODA_APP
はOracle Databaseロールです。SODA Developer
はアプリケーション・サーバー・ロールです。
関連項目:
ORDSのセキュリティ機能の詳細は、Oracle REST Data Servicesインストレーション、構成および開発ガイドを参照してください
- 認証メカニズム
ORDSは、様々な認証メカニズムをサポートしています。JSONドキュメント・ストアRESTサービスは、サーバー間の相互作用に使用されることを意図しています。このため、JSONドキュメント・ストアRESTサービスで使用する認証メカニズムとしては、Two-Legged OAuth(クライアント資格証明フロー)をお薦めします。しかし、HTTP Basic認証など、その他のメカニズムもサポートされています。 - 開発およびテストに関するセキュリティの考慮事項
開発およびテストに関するセキュリティの考慮事項について説明します。
6.1 認証メカニズム
ORDSは、様々な認証メカニズムをサポートしています。JSONドキュメント・ストアRESTサービスは、サーバー間の相互作用に使用されることを意図しています。このため、JSONドキュメント・ストアRESTサービスで使用する認証メカニズムとしては、Two-Legged OAuth(クライアント資格証明フロー)をお薦めします。しかし、HTTP Basic認証など、その他のメカニズムもサポートされています。
親トピック: セキュリティ
6.2 開発およびテストのセキュリティ上の考慮事項
開発およびテストのセキュリティ上の考慮事項を示します。
次のように、デフォルトの権限マッピングを削除することで、セキュリティを無効にし、匿名アクセスを許可できます。
exec ords.delete_privilege_mapping('oracle.soda.privilege.developer', '/soda/*')
しかし、本番システムで匿名アクセスを許可することはお薦めしません。匿名アクセスの許可は、認証されていないユーザーに任意のコレクションの読取り、更新、またはドロップを許可することになります。
また、ords.war user
コマンド使用して特定のロールを持つテスト・ユーザーを作成できます。この例では、プレースホルダ<user_name>
と<password>
を適切なユーザー名と<password>に置き換えています。
# Create a user with role SODA Developer.
# (Be sure to replace placeholder <user_name> here.)
java -jar ords.war user <user_name> "SODA Developer"
# Access the JSON document store using basic authentication.
# (Be sure to replace placeholders <user_name> and <password> here.)
curl -u <user_name>:<password> https://example.com/ords/scott/soda/latest/
親トピック: セキュリティ