こんにちは。kuuです。

自社で管理をしているアカウントにサーバを立ち上げ他社に保守を依頼する際に
アカウントで行えるフル権限を与えるのはリスクが多いですよね。

また、複数人でさくらのクラウドを利用すると、サーバは見せたいが操作させたくない、
電源操作だけ許可したい、作成・削除まではさせたくない、といったケースがあります。

今回は検証用ユーザーpolicy-testを作成して、アクセスレベルによって実際にどこまで操作できるのか確認します。
後半では、サービスポリシーによるゾーン制限を設定し、ドライランと本適用での挙動を確認していきます。

今回の検証用に以下を使用していきます。

検証ユーザー：policy-test
検証用サーバ：policy-test-server

アクセスレベルとは

IAMポリシーでは、ユーザーなどにロールを付与することで、さくらのクラウド上で行える操作を制御できます。

アクセスレベル	主な権限
リソース閲覧	リソースを見る
電源操作	閲覧＋サーバ/アプライアンスの電源操作
設定編集	電源操作＋既存リソースの設定変更など
作成・削除	課金増減を伴う作成・削除を含む全操作

詳細につきましては公式マニュアルにて記載がございますのでそちらをご確認ください

https://manual.sakura.ad.jp/cloud/controlpanel/access-level.html

「リソース閲覧」でシャットダウン

まずは検証ユーザーに対しリソース閲覧の権限を付与していきます。

リソース閲覧のみをつけた状態のユーザでシャットダウンを行おうとするとエラーが出ます。

「作成・削除」で再度シャットダウン

では次に作成・削除の権限をつけた状態だとどうなるか確認します。

シャットダウンを行うことが出来ました。

「作成・削除」には下位のアクセスレベルの権限も含まれるため、サーバの作成・削除だけでなく、
シャットダウンなどの電源操作も実行できます。

アクセスレベル権限比較表に関しまして、下記マニュアルよりご確認ください。

https://manual.sakura.ad.jp/cloud/controlpanel/access-level.html#id8

例えば、復旧対応などでサーバの再起動まで行ってほしい際は「電源操作」
スペックアップやスペックダウンを行ってほしい際は「作成削除」など
作業内容に合わせてアクセスレベルを分けることができます。

サービスポリシーとは

ここまでは、policy-testユーザーにIAMポリシーを設定してアクセスレベルを確認していきました。
ここからはサービスポリシーについて触れていきます。

サービスポリシーの公式マニュアルは下記をご確認ください。

https://manual.sakura.ad.jp/cloud/controlpanel/settings/service-policy.html

以下はさくらのクラウドにおける組織、フォルダ、プロジェクトの例です。

組織（会員IDに対して1つ作成される最上位の階層）
├─ 本番フォルダ
│ ├─ 本番Webプロジェクト
│ └─ 本番DBプロジェクト
│
├─ 開発フォルダ
│ └─ 開発プロジェクト
│
└─ 検証フォルダ
└─ 検証プロジェクト

このような場合サービスポリシーはプロジェクトやユーザに設定するのではなく、
組織のルールとして全体に適用される形となります。

サービスポリシーを試す

検証として先ほど作成した、policy-testにサーバを作成・削除の権限を与えたまま、
「石狩第3ゾーン以外ではサーバを作成させない」といった組織側の制限をかけたい場合はどうなるのか
確認していきましょう。

実環境で利用する際の注意点

実際の環境で、同一組織内に本番・開発など複数のプロジェクトが存在する場合、
サービスポリシーは組織単位で適用されるため、特定のプロジェクトだけを対象にすることはできません。
まずドライランで影響を確認してから本適用を検討する必要があります。

サービスポリシーの設定

個人の検証環境となります。

まず、コントロールパネルで対象の組織を選択します。

普段は、検証用プロジェクトAでサーバを立ち上げたりしておりますが、
サービスポリシーを適用させるとプロジェクトAだけでなくプロジェクトBにもそのルールが適用されます。

サービスポリシーの有効を選択し保存します。

現在はまだ適用されていない6つのルールが出てきました。
ルールの一覧及び詳細は下記公式マニュアルよりご確認ください。

https://manual.sakura.ad.jp/cloud/controlpanel/settings/service-policy.html#id11

今回はゾーン制限のルールテンプレートを使用していきます。
ルールID：cloud-restrict-zone

ゾーンの表記は下記になります。

ゾーン	識別子
石狩第1ゾーン	is1a
石狩第2ゾーン	is1b
石狩第3ゾーン	is1c
東京第1ゾーン	tk1a
東京第2ゾーン	tk1b
サンドボックスゾーン	tk1v

ドライラン適用の場合はブロックはされずにログに記録されるのみとなります。

ドライランで影響を確認する

サービスポリシーをドライランで適用した場合、ルールに違反する操作があっても、
操作そのものはブロックされません。

操作は実行されますが、違反内容がイベントログに記録されます。

今回は、「石狩第3ゾーンのみを許可する」つもりで設定したものの、
誤って石狩第3ゾーンを拒否する設定になっていたケースを想定します。

ドライランを有効にしているため、操作そのものはブロックされませんでした。

このように、ドライランを使うことで、実際の操作を停止させることなく、
設定内容や影響範囲を事前に確認できます。

ドライランを解除して本適用する

続いて、許可するゾーンを石狩第3ゾーンのみに戻し、ドライランを解除します。

その状態で、許可されていない石狩第1ゾーンを選択し、サーバの作成を試します。

石狩第1ゾーンを選択した時点で、サービスポリシーに関する警告が表示されました。

そのままサーバの作成を進めると、作成画面でも権限エラーが表示され、操作がブロックされました。
イベントログにも、サービスポリシーに違反した操作として記録されています。

イベントログに関してはCSVでもダウンロードができます。

"日時","認証方法","接続元","ゾーン","ログ種別","内容" 
"2026-08-17 (月) 13:52:56","ユーザ policy-test@xxxxxxxx","xx.x.xx.xxx","石狩第1ゾーン","ルール違反の操作","GET /noteはcloud-restrict-zoneに違反しました" 
"2026-08-17 (月) 13:52:56","ユーザ policy-test@xxxxxxxx","xx.x.xx.xxx","石狩第1ゾーン","ルール違反の操作","GET /secretmanager/vaultsはcloud-restrict-zoneに違反しました" 
"2026-08-17 (月) 13:52:56","ユーザ policy-test@xxxxxxxx","xx.x.xx.xxx","石狩第1ゾーン","ルール違反の操作","GET /kms/keysはcloud-restrict-zoneに違反しました"