はじめに
AWS環境にてRDSインスタンスの構築検証を行っていた際、Oracle Databaseのライセンスを所持していないにも関わらず、誤って BYOL（Bring Your Own License）モデル でインスタンスを構築してしまうという事象が発生しました。（やらかしました。）
本記事では、なぜライセンス未所持で構築できてしまったのかという仕様の解説と、同様の誤操作を防ぐためにSCPやIAMポリシーを用いてBYOLモデルの構築を制限する方法について共有します。
発生した事象
検証にて様々なDBエンジンの構築と削除を繰り返していました。その際、以下の条件でRDS for Oracleの作成を行いました。
- Engine: Oracle Standard Edition 2 (SE2)
- License Model: Bring Your Own License (BYOL)
設定完了後、コンソール上でエラーや警告が表示されることなくプロビジョニングが開始され、インスタンスステータスは Available となりました。しかしその後、ライセンスモデルが「License Included」ではなく「BYOL」となっていることが判明し、即座に削除を行いました。
誤認していた点
構築時、以下の点を誤認していました。
- ライセンスキー入力の必須化: BYOLを選択した場合、構築ウィザード内でライセンスキーや証書の確認プロセスがあると考えていました。
- AWS側のチェック: 有効なライセンスを持たないアカウントでは、BYOLでの構築が自動的にブロックされると想定していました。
AWSにおけるRDS for Oracle BYOLの仕様
AWSの仕様上、RDS for OracleのBYOLモデルを選択しても、コンソールやAPIでの構築時に ライセンス情報の入力や検証は行われません。
AWSはインフラを提供する立場であり、ソフトウェアライセンスについては「ユーザーがOracle社と適切な契約を結んでいること」を前提としています。そのため、ライセンスを所持していない状態でも、操作自体は完了してしまいます。
誤構築による潜在的リスク
ライセンスコンプライアンスリスク
意図せずBYOLで構築し稼働させ続けた場合、以下のような重大なリスクが発生します。
- 監査時の指摘対象: Oracle社によるライセンス監査で違反と判定される可能性
- 追徴課金: 過去の使用期間に遡ってライセンス料を請求されるケース
- 契約上の信頼損失: ベンダーとの関係悪化
コスト面での誤解
BYOLモデルは「ライセンス料が含まれないため安価」と誤解されがちですが、実際には以下の点に注意が必要です。
- AWS利用料: License IncludedよりもBYOLの方が若干低額（ライセンス分が含まれないため）
- Oracle社へのライセンス料: 別途、Oracle社との直接契約に基づく支払いが必要
- トータルコスト: ライセンス所持がない場合、License Includedの方が結果的に適切
参考: AWS公式 - RDS for Oracleライセンスオプション
再発防止策：IAMポリシーによる制限
「操作ミス」や「仕様の誤認」による誤構築をシステム的に防ぐため、IAMポリシーを使用して 「特定のライセンスモデル（BYOL）でのRDS構築を拒否する」 設定を行います。
方針
- IAMユーザーまたはロールに対し、RDSの操作権限は許可する
- ただし、条件キー
rds:LicenseModelがbring-your-own-licenseの場合のみ、作成および復元アクションを明示的に拒否（Deny）する
実装するIAMポリシー
以下のJSONポリシーを作成し、対象のIAMユーザーやグループにアタッチします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRDSBringYourOwnLicense",
"Effect": "Deny",
"Action": [
"rds:CreateDBInstance",
"rds:RestoreDBInstanceFromDBSnapshot",
"rds:RestoreDBInstanceToPointInTime"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:LicenseModel": "bring-your-own-license"
}
}
}
]
}
ポリシーの解説
-
Effect: Deny: 条件に合致した場合、操作を拒否します。IAMの評価ロジックでは Deny が Allow より優先 されるため、管理者権限（AdministratorAccess）を持つユーザーであっても、このポリシーが適用されていれば操作はブロックされます。
-
Action:
-
rds:CreateDBInstance: インスタンスの新規作成 -
rds:RestoreDBInstanceFromDBSnapshot: スナップショットからの復元 -
rds:RestoreDBInstanceToPointInTime: ポイントインタイムリカバリ
-
注意: 新規作成だけでなく、リストア時に誤ってBYOLモデルが選択されることも防止します。
-
Condition:
-
rds:LicenseModel: RDSのライセンスモデルを判定する条件キーです -
bring-your-own-license: BYOLモデルを指定する値です
-
AWS Organizationsでの一括適用（応用編）
複数アカウントを管理している場合、Service Control Policy (SCP) を使用して組織全体に制限を適用できます。
SCPの実装例
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRDSBYOLAcrossOrganization",
"Effect": "Deny",
"Action": [
"rds:CreateDBInstance",
"rds:RestoreDBInstanceFromDBSnapshot",
"rds:RestoreDBInstanceToPointInTime"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "oracle-se2",
"rds:LicenseModel": "bring-your-own-license"
}
}
}
]
}
IAMポリシーとSCPの使い分け
| 方式 | 適用範囲 | 用途 |
|---|---|---|
| IAMポリシー | 特定のユーザー/ロール | 個別の権限制御 |
| SCP | 組織単位（OU）またはアカウント全体 | 組織全体のガードレール |
推奨: 環境全体で制限する場合はSCPを使用し、特定チームのみ許可する場合はIAMポリシーで制御を行う。
動作確認
ポリシー適用後、実際にRDS作成画面から「Oracle Standard Edition 2 (BYOL)」を選択して作成を試みると、以下のようなエラーが発生し、構築がブロックされることを確認しました。
User: arn:aws:iam::xxxxxxxx:user/test-user is not authorized to perform: rds:CreateDBInstance on resource: ... with an explicit deny
一方で、「License Included」を選択した場合は、正常に構築プロセスが進行します。これにより、ライセンス違反のリスクをシステム側で排除することが可能となりました。
まとめ
RDS for Oracleなど一部のDBエンジンでは、ライセンス検証なしでBYOLモデルの構築が可能です。
オペレーションミスによるライセンスリスクを回避するためには、運用ルールだけでなくシステム的なガードレールが有効です。
IAMポリシーの rds:LicenseModel 条件キーを活用することで、ライセンスモデルに基づいたきめ細やかな権限管理が実現できます。