Azureポリシーを使用したOracle AI Database@Azureデプロイメントの管理 (2026/09/11)
Azureポリシーを使用したOracle AI Database@Azureデプロイメントの管理 (2026/09/11)
https://blogs.oracle.com/cloud-infrastructure/azure-policy-oracle-ai-database-azure
投稿者：Julien Silverston | Solution Architect Multicloud
Ram Kakani | Principal PM Manager – Azure
はじめに
Oracle AI Database@Azureは、組織がOracleに依存するワークロードをAzureに移行する際に、ビジネスに適したデータベースアーキテクチャ、ライセンスモデル、接続性、および運用管理を選択できるように支援します。導入が進むにつれて、エンタープライズの準備態勢は、Azureポータル、自動化、またはAPIのいずれでデプロイメントを作成するかに関わらず、これらの選択を一貫性のある再現可能な標準にすることが鍵となります。
Azure Policy は、組織が承認した運用モデルを自動化されたガードレールに変換します。 Oracle.Database これにより、次のようなリソースタイプに対するデプロイ要件を強制できます。
- ライセンス管理： 導入にあたっては、組織が承認したライセンスモデルを使用する必要があります。
- ネットワークアクセス： 導入にあたっては、承認されたプライベートネットワークモデルの使用が求められる場合があります。
- 制御管理： 重要なリソースを意図しない削除から保護できます。
このポリシーは、リソースの作成または更新前にリクエストを評価します。まずデフォルトの Audit 効果から始めて影響を理解してください。効果を変更すると Deny、ポリシーに準拠していないデプロイメントはデプロイメントの時点で停止されます。これにより、チームはガバナンスを早期に導入し、手動レビューを減らすことができます。
プラットフォームチームは、承認済みのベースラインを一度定義し、適切な管理グループ、サブスクリプション、またはリソースグループのスコープに割り当てます。アプリケーションチームとデータベースチームは、既存のツールを使用して安心してデプロイできます。準拠するリクエストは追加の承認手順なしで処理され、例外は即座にフィードバックされます。これにより、チームはOracle AI Database@Azureをより迅速に導入できる俊敏性を得ることができ、企業が必要とする運用制御、セキュリティ、および一貫性を損なうことなく導入できます。
このアプローチは、Oracle AI Database@Azure の一貫したデプロイメント標準を必要とするクラウドプラットフォーム、セキュリティ、FinOps、およびデータベースガバナンスの各チームを対象としています。アプリケーションチームはセルフサービスによるデプロイメントを維持しつつ、プラットフォーム側で承認済みのベースラインを確立します。
実践例：ライセンスモデルの標準化
ライセンスは、商用上の決定を一貫したデプロイメント体験へと変換する上で、有用な最初の安全策となります。この例は、BYOL（Bring Your Own License：ライセンスベース）デプロイメントの標準化という顧客要件に基づいています。汎用的な内容で提示されており、承認済みの別のモデルにも適用可能です。プラットフォームチームが承認済みモデルを一度選択すると、Azure Policy がポータル、CLI、Terraform、ARM、API デプロイメント全体に一貫して適用します。
- BYOL標準： Oracle ULAなどの組織が承認したライセンス戦略でBYOLが要求されている場合、
BringYourOwnLicenseライセンス同梱の展開を要求し、防止します。 - ライセンス付属標準:
LicenseIncludedBYOL用に構成されたデプロイメントを 必須とし 、防止します。
この記事のポリシー定義は、最初のシナリオであるBYOL（Bring Your Own License：ライセンスの自己所有）を実装しています。ライセンス付属を承認している組織の場合は、必須値としてLicenseIncludedを指定して、同じポリシーパターンを使用してください。適用する前に、ライセンスチームおよび調達チームと適切なモデルを確認してください。
まずはモードで開始し Audit 、Oracle AI Database@Azureをデプロイするチームと影響を確認し、 Deny 承認された構成が明確になったら移行します。これにより、アプリケーションチームとデータベースチームは迅速なセルフサービスデプロイが可能になり、プラットフォームチームは明確で監査可能なライセンスベースラインを維持できます。
ポリシー行動
このポリシーは、 Oracle.Database/autonomousDatabases 以下のいずれかの条件が満たされた場合に、一致するデプロイメントをターゲットにして拒否します。
licenseModel 欠落しています。licenseModel そうではありません BringYourOwnLicense。
Azure Oracle Database REST API の ドキュメントで は、省略したLicenseIncluded 場合のデフォルト値として が指定されています licenseModel 。このポリシーでは、明示的に BYOL を選択することを意図的に要求しており、省略された値によってデフォルト値が暗黙的に使用されることを防ぎます。ポリシーを適用する前に、ご使用の環境で使用されている API バージョンとデプロイ パスに対してこの動作を確認してください。
このポリシーでは、以下の Oracle Database@Azure プロバイダーエイリアスを使用します。
Oracle.Database/autonomousDatabases/licenseModel
以下の方法でエイリアスを見つけましょう：
az provider show \
--namespace Oracle.Database \
--expand "resourceTypes/aliases" \
--query "resourceTypes[?resourceType=='autonomousDatabases'].aliases[].name" \
--output tsvエイリアスの検出と使用に関する一般的なガイダンスについては、 「Azure Policy 定義構造のエイリアス」を参照してください。
ポリシー定義の例
Autonomous Database リソースのみを対象とするカスタムポリシー定義を作成します。
{
"properties": {
"displayName": "Require BYOL for Oracle Autonomous Database deployments",
"description": "Audits or denies Oracle AI Database@Azure Autonomous Database create or update requests when licenseModel is missing or is not BringYourOwnLicense.",
"policyType": "Custom",
"mode": "Indexed",
"metadata": {
"category": "Oracle.Database",
"version": "1.3.0"
},
"parameters": {
"effect": {
"type": "String",
"allowedValues": [
"Deny",
"Audit",
"Disabled"
],
"defaultValue": "Audit"
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Oracle.Database/autonomousDatabases"
},
{
"anyOf": [
{
"field": "Oracle.Database/autonomousDatabases/licenseModel",
"exists": "false"
},
{
"field": "Oracle.Database/autonomousDatabases/licenseModel",
"notEquals": "BringYourOwnLicense"
}
]
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
}
}
}ポリシーを作成して割り当てる
購読コンテキストを設定します。
az account set --subscription "<subscription-id-or-name>"</subscription-id-or-name>カスタムポリシー定義を作成または更新します。
SUB_ID="<subscription-id>"
az rest \
--method PUT \
--url "https://management.azure.com/subscriptions/${SUB_ID}/providers/Microsoft.Authorization/policyDefinitions/require-oracle-autonomous-database-byol?api-version=2023-04-01" \
--body @policies/require-autonomous-database-byol.json</subscription-id>サブスクリプションの範囲でポリシーを割り当てます。
az rest \
--method PUT \
--url "https://management.azure.com/subscriptions/${SUB_ID}/providers/Microsoft.Authorization/policyAssignments/require-adb-byol?api-version=2022-06-01" \
--body @policies/assign-require-autonomous-database-byol.json範囲とアクセスへの影響
Azure Policy は、ユーザー グループではなく、Azure リソース スコープに割り当てられます。この割り当ては、そのスコープ内のリソースとすべての子リソースに適用されます。
- 管理グループ： 複数のサブスクリプションに同じ基準を適用する必要がある場合に使用します。
- サブスクリプション： 1つのサブスクリプション内のすべてのOracle Database@Azureデプロイメントがベースラインに従う必要がある場合に使用します。この記事では、この範囲を使用します。
- リソースグループ： ワークロードまたは環境に対して、より的を絞った展開が必要な場合に使用します。
- 個別リソース： 例外的な、限定された範囲の制御にのみ使用してください。
このポリシーは、割り当てられたスコープ内で一致する要求を送信するすべてのユーザー、サービスプリンシパル、および管理対象IDに影響します。ただし、そのIDがAzure RBACで当該アクションを実行する権限を持っていることが前提となります。Azure Policyはアクセス権の付与や削除は行わず、承認された要求に対してコンプライアンスチェックを追加します。 リソースのデプロイや管理を誰が行えるかを決定するにはAzure RBACとMicrosoft Entra IDグループを使用し、許可される構成やアクション を決定するにはAzure Policyを使用してください 。
保険適用除外の申請
ワークロードにBYOLを使用しない明確なビジネス上または技術的な理由がある場合、その所有者はプラットフォームまたはガバナンスチームにポリシーの免除を申請できます。免除は個々のリソースまたはリソース階層に限定でき、 Azure Policyコンプライアンスレポートでは「免除」として表示され 、有効期限を設定できます。免除は、特定の期間を定めた例外にのみ使用し、ベースラインポリシーを弱めたり、単一のワークロードに対して広範な除外を設定したりしないでください。
Azureでは明示的な免除権限が必要となるため、プラットフォームチームまたはガバナンスチームが免除内容を確認し、作成する必要があります。 免除モデル、カテゴリ、有効期限、および必要な権限については、「Azure Policyの免除構造」を参照してください。
誤削除を防ぐ
この記事で紹介する BYOL ポリシーは、この Deny 効果を使用して、準拠していない作成および更新要求を停止します。重要なリソースを誤って削除されないように保護するには、Azure Policy の denyAction 効果と delete アクションを使用する別のポリシーを作成します。この補完的な制御は 403 Forbidden 、一致する削除要求に対して返されます。削除保護は、独立したバージョン管理された別のポリシーとして保持し、適用前に非運用サブスクリプションでリソース グループ、親/子、およびカスケード削除の動作を検証してください。
執行の検証
監査モードでのテスト後、以下のいずれかの設定で自律型データベースを作成してみてください。
Azure は、以下の理由でデプロイをブロックします。
Resource '<database-name>' was disallowed by policy.
Code: RequestDisallowedByPolicy
Policy: Require BYOL for Oracle Autonomous Database deployments</database-name>以下の手順で準拠したデプロイメントを作成します。\
licenseModel = BringYourOwnLicense本番環境への展開前に、ポータル、CLI、自動化、サポートされている Terraform または ARM/Bicep ワークフロー、既存のリソースの更新、省略されたリクエスト licenseModel 、および承認されたポリシー免除動作もテストします。
コンプライアンスチェック
ポリシースキャンを実行します。
az policy state trigger-scan --subscription "${SUB_ID}"
割り当て対象となるポリシーの状態を一覧表示します。
az policy state list \
--subscription "${SUB_ID}" \
--policy-assignment require-adb-byol \
--query "[].{resource:resourceId, compliance:complianceState, action:policyDefinitionAction}" \
--output table既存の一致するリソースは、コンプライアンスの観点から評価されます。このポリシーは、既存の非準拠リソースを削除するのではなく、BYOL要件を満たさない作成および更新リクエストのマッチングを防止します。 Audit 展開時には、コンプライアンスレポートによって、チームはポリシーの適用前にその影響を把握することができます。
ロールバック
割り当てパラメータを に変更することで、割り当てを削除せずに強制を無効にします Disabled。
{
"parameters": {
"effect": {
"value": "Disabled"
}
}
}制御が不要になったら、割り当てを削除してください。
az policy assignment delete \
--name require-adb-byol \
--scope "/subscriptions/${SUB_ID}"他のサブスクリプションで再利用される場合は、定義を保持してください。すべての割り当てが削除された後にのみ、定義を削除してください。
まとめ
ガバナンスは、承認されたパスを最も容易なパスにするべきです。Azure Policyで検証済みのライセンス要件を明示することで、プラットフォームチームはアプリケーションチームとデータベースチームにデプロイの自由度を与えつつ、すべてのデプロイが組織のガイドラインを最初から満たすことを保証できます。
パイロット割り当てをモードで開始し Audit 、Oracle AI Database@Azure をデプロイするチームと結果を確認し、サポートされている各デプロイ パスを検証してから、 Deny 期待される動作が確認されたら移行します。該当するリソース タイプとプロバイダー エイリアスを選択することで、他の Oracle AI Database@Azure リソース タイプにも同じポリシー パターンを再利用します。ネットワーク アンカー モデルが進化するにつれて、検証済みの要件をこのライセンス ベースラインに結合させるのではなく、別のバージョン管理されたポリシーを通じて追加します。
このアプローチでは、単発のレビューを、拡張性と一貫性のある管理に置き換えます。チームはデプロイ中に迅速なフィードバックを得ることができ、ライセンス基準は一律に適用され、コンプライアンス状況はAzure Policyの画面上で確認できます。その結果、プラットフォームチームが大規模なガバナンスを実現しつつ、アプリケーションチームとデータベースチームが生産性を維持できる、エンタープライズ対応のサービスモデルが実現し、Oracle AI Database@Azureへの移行とイノベーションが加速します。
コメント
コメントを投稿