ClaudeでAlibaba Cloudのセキュリティグループ運用を自動化する方法

要点： セキュリティグループの規則を書き出し、意図する方針と一緒にClaudeへ渡すと、広すぎる許可、誰も必要としていない規則、重複や無効化された規則、環境間の乖離が、確認できる差分として順位つきで返ってきます。これで作業の八割が片づきます。適用は依然として人の承認と変更記録を通します。本番のセキュリティグループへ書き込める権限を持つAIエージェントは、作るべき形ではありません。

セキュリティグループに規則が四十個たまることを、誰も計画していません。切迫した金曜日が一度ずつ積み重なった結果です。取引先がアクセスを必要とし、業務委託が何かを調べており、監視ツールがあるポートに届かない。追加された日には、どの規則も筋が通っていました。二年後、どれがまだ必要なのかを言える人はおらず、「test-rule-3」という名前の規則は、それを知っていたかもしれない三人より長く生き残っています。

これが続く理由は怠慢ではありません。規則を手で見直す作業は本当に退屈で目に見える報酬がなく、環境全体を一度に頭へ入れる必要があり、そして個々の判断点で最も安全に感じる行動は「触らないこと」です。こうして規則は積み上がり、攻撃面は静かに広がります。

これは言語モデルが実際に得意な種類の問題です。大きな構造化データを読み、平易な言葉で述べた方針と突き合わせ、「おかしく見えるもの」を具体的に順序立てて出す。得意でないのは「このポートを閉じたら本番が壊れるか」の判断で、だからこそ適用する側は人の仕事のままです。

セキュリティグループが腐る理由

どこでも同じ型が出ます。名前をつけるだけで作業の半分は終わります。

一時的な規則が恒久化する。 移行、ベンダーのデモ、障害調査のために開けたアクセスが閉じられない。閉じる期限もなく、担当者もいないからです。

管理用ポートに世界中から届く。 SSHやRDPに0.0.0.0/0という送信元範囲が付いているのは最もよくある重大な指摘で、たいていは誰かが急いで自分を通し、あとで絞るつもりだった結果です。

規則に持ち主も期限もない。 規則を説明できたはずの欄は任意なので空です。そして「これはまだ必要か」と問う仕組みが存在しません。

環境が乖離する。 検証環境は十八か月前に本番から複製され、以後それぞれに変化し、誰も比べていません。検証側のほうが緩い規則と同じデータを抱えていることも珍しくありません。

重複と無効化された規則がたまる。 範囲が重なる二つの規則。片方は決して効かず、それでも消す影響が読めないので両方とも誰も触れません。

現在の状態をAlibaba Cloudから取り出す

何を、どう書き出すか

Alibaba CloudはECSのAPIと、その上のコマンドラインツールでセキュリティグループの一覧を扱えます。必要なのは「グループを列挙する」操作と「個々のグループの規則を取得する」操作の二つで、正確な操作名と引数は断片的なコード例ではなく現在のAPI資料で確認する価値があります。仕様は変わるからです。

書き出すのは規則だけではありません。規則は文脈の中でしか判断できないので、各グループが属するVPCとリージョン、グループごとの全規則、そして各グループに実際に紐づいているインスタンスまで取得します。最後の項目は聞こえ以上に重要です。何も紐づいていない緩いグループと、データベースを守っている同じ設定のグループは、別の問題です。

運用しているすべてのリージョンで行ってください。自然に育った環境には、たいてい忘れられたリージョンで何かが動いています。思い浮かぶリージョンだけを見た点検は、面白い指摘を取り逃がす点検です。

分析には、どのRAM権限が要るか

読み取り専用で、これは形式ではありません。分析はセキュリティグループとインスタンスを参照するだけなので、何も変更できないRAM主体で動かすべきです。Alibaba CloudはECS向けの読み取り専用ポリシーを用意しています。現在の名称と正確な範囲は、記憶に頼らずRAMの画面で確認してください。

衛生上の話を超えて、これが効く理由が二つあります。第一に、読み取り専用の資格情報は「報告のつもりの自動化が変更してしまう」事故の一群をまるごと消します。最も恐れていたことが、意図の問題ではなく構造上あり得ないことになります。第二に、承認者との会話が変わります。「読み取り専用の書き出しを、人が確認し、人が適用する」は通りやすく、「ファイアウォールへ書き込めるエージェント」はそうではありませんし、そうであるべきでもありません。

資格情報は他の本番の秘密と同じ扱いで保管し、期限を設けてください。長命のアクセスキーがスクリプト置き場に転がっているほうが、この点検が見つける大半の問題より重大です。

Claudeに何を探させるか

指摘が出る四つの問い

まず意図する方針を述べます。どのポートならインターネットに開けてよいか、管理アクセスに許容できる送信元は何か、各環境はどうあるべきか。そのうえで照らして問います。方針を述べなければ、モデルは一般的な最善策を当てはめ、あなたが反論したくなる指摘を返します。

広すぎる送信元。 広い公開範囲を許している規則を、その背後にあるものの順に並べる。まず管理用ポート、次にそれ以外。各グループに紐づくインスタンス名も添えさせれば、読む側が深刻度を判断できます。

必要としているものが見当たらない規則。 稼働しているどのサービスにも対応しないポート、インスタンスの付いていないグループ、取引の終わった業者を指す送信元。モデルが提案し、確認するのはあなたです。モデルに通信は見えません。

重複と無効化。 範囲が重なり、一方が他方を無意味にしている組み合わせ。四十個の規則から手で見つけるのは退屈で、全部を一度に読むモデルには造作もありません。

環境間の乖離。 二つの書き出しを渡し、どこが違うかを問う。手作業では誰もやらない点検で、意外な指摘はしばしばここにあります。

小論文ではなく差分を求める

出力の形が、これが定着するかどうかを決めます。セキュリティ態勢を語る文章は行動に移せず、二度読まれません。

求めるべきは、提案一件につき一行です。どのグループの、どの規則を、何に変え、なぜで、深刻度はどれか。それを実現する具体的なAPI呼び出しか画面操作まで求めれば、確認する人は助言を解釈するのではなく具体的な操作を点検できます。そして各項目に「影響範囲」——これが誤りだった場合に何が止まるか——を必ず添えさせてください。確認者が本当に必要とする欄であり、求めなければモデルが省く欄です。

提案は分析と分けて置きます。変更を承認する人が読むべきは変更の一覧であって、説明の中からそれを探すことではありません。

定期的なガバナンスの輪

五段階、この順で、毎回同じに。

書き出す——誰かが思い出したときではなく、決めた頻度で。分析する——述べた方針に照らして。確認する——提案された差分を人が見て、影響範囲が読めないものは差し戻す。適用する——他のファイアウォール変更と同じ通常の変更手続きと承認を通して。記録する——何を、なぜ、誰が承認したか。

変化の多い環境なら書き出しと分析は毎月、安定した環境なら四半期でも筋が通ります。間隔より大事なのは輪が閉じることです。誰も確認しない分析は、分析がないより悪い。作業が済んだように見える記録だけが残るからです。

AI支援の規則点検 vs クラウドネイティブの設定ツール vs マネージドセキュリティ

• 始める費用 — AI支援の点検の勝ち。書き出しと指示と午後半日です。
• 意図の理解 — AI支援の点検の明確な勝ち。ネイティブのツールは一般的な最善策に照らしますが、モデルはあなたが書いた方針、意図して残した例外も含めて照らせます。
• 継続的で自動の評価 — クラウドネイティブの設定ツールの勝ち。誰も覚えていなくても走ります。覚えている必要があることは、あらゆる手作業の失敗要因です。
• セキュリティグループを超える範囲 — ネイティブのツールもマネージドサービスも、書き出した分しか見えない単発の点検には勝ります。
• 結果に責任を負う人 — マネージドセキュリティの圧勝。技術者が忙しいかどうかに関わらず点検は起き、結果は他者が担います。
• 監査に出せる証拠 — マネージドサービスの勝ち。日付と承認の経路が付いた報告書は監査人が受け取りますが、チャットの記録は受け取られません。

これらは競合ではなく積み重ねです。一度も点検されたことのない環境を片づけるならAI支援が最速で、ネイティブの設定ツールは再び腐るのを防ぎ、忙しさに負けずに規律を続ける必要があるならマネージドサービスを買うことになります。

自動化してはいけない部分

三つ。ガバナンスと事故を分ける線です。

変更は必ず人が承認する。 モデルは提案し、文脈を持つ人が決める。提案が明らかに正しいときでもこれは変わりません。「明らかに正しい」こそ、自動化にはできず人にはできる判断だからです。

変更は必ず記録を残す。 何を、いつ、誰が承認し、理由は何か。次の点検を可能にするものであり、監査人が求めるものです。

変更には必ず戻し方がある。 適用前に、元の状態と復旧手順を把握しておく。変更前の書き出しを保管してください。それが戻し方です。

そして三つの下にある立場。本番のセキュリティグループに対して自動適用の輪を作らないこと。 人を通さずにポートを開けられるエージェントは、出発点の問題の新しく、より悪い版です。読んで提案するのが形であり、適用は判断です。

正しく進めるために——RAMの資格情報、変更管理、ITに任せる範囲

意識して決めておく価値のあることが三つあります。

第一に資格情報。分析に必要な範囲に絞った読み取り専用のRAM主体を、期限つきで、他の本番の秘密と同じ扱いで保管する。同じ自動化が後で適用まで行う必要が出たなら、それは別の主体、別の承認、別の議論です。最初のものの権限を広げる話ではありません。

第二に何が環境の外へ出るか。セキュリティグループの書き出しは、あなたの攻撃面の地図です。どのポートが、どこから開いていて、何を守っているか。これは本当に機微で、どこへ送るかは習慣ではなく判断に値します。使っている製品階層のデータ取り扱いと学習利用の条件を、思い込みではなく読んでください。法人向けと消費者向けは異なるのが普通で、条件も変わります。同じ理由から、社内AIアシスタントについて扱った中国のデータ所在の論点がここにも当てはまります。

第三に全員が忙しいとき、誰がこの輪を回すか。衰えるのはここです。ファイアウォール規則の変更と調整、毎月の差分分析、四半期ごとの設定バックアップは、まさに管理型ITセキュリティサービスが意向ではなく継続する規律として扱う範囲です。AI+サポートはこの種の自動化を統制された資格情報と会社アカウントの上に整えることを支援し、管理型ITサポートはその周りのアクセスのライフサイクルを扱います。Brocentは2007年の北京での創業以来アジアで管理型ITとセキュリティを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

AIエージェントがセキュリティグループの変更を自動適用してよいことはありますか？

本番に対してはありません。問題はモデルが時々間違えることではなく、間違えたときに誰も気づかないことです。記録には「人ではなく仕組みが承認して変更した」と残るからです。モデルは分析と提案に留め、規則を変えるものの前には人と変更記録を置いてください。

分析には実際どのRAM権限が必要ですか？

セキュリティグループ、その規則、紐づくインスタンスを参照する読み取り権限だけです。Alibaba CloudはこれをカバーするECSの読み取り専用ポリシーを公開しています。名称と範囲は記事から写すのではなくRAMの画面で確認してください。提案された権限の集合に変更できるものが含まれているなら、この用途には誤った集合です。

規則の一覧をAIツールへ書き出すと露出になりますか？

現実的な検討事項です。その書き出しはあなたの攻撃面そのものを記述しています。意識して決めてください。使う階層のデータ取り扱い条件を確認し、法人向け階層を優先し、分析が壊れない範囲でインスタンス識別子を伏せることも検討します。それが許容できない環境では、同じ手法を自社設置のモデルや、規則ベースの点検スクリプトでも実現できます。

どのくらいの頻度で回すべきですか？

変化の多い環境なら毎月、安定した環境なら四半期ごと、そして大きな移行や新環境の追加の直後には必ず。間隔より輪が閉じることが重要です。誰も確認しない書き出しは保護を与えず、誤解を招く記録だけを作ります。

MLPS（等級保護）などの監査要件とはどう噛み合いますか？

ネットワークのアクセス制御を定期的に見直し、証跡を残すことは、中国のMLPS制度を含む多くの枠組みで一般的に期待されています。この輪が生む成果物——日付入りの書き出し、文書化した方針、確認済みの提案、承認、変更記録——は監査人が求める証拠の形です。自社の等級に適用される具体的な要件は、これで満たされると仮定せず、資格のある評価機関に確認してください。

実際に使われている規則はモデルに分かりますか？

規則の一覧だけからは分かりません。分かるのは、あなたが説明したサービスに照らして不要に見える規則までです。実際の利用状況には通信データが要り、それは別途あなたが用意する情報源です。「使われていないように見える」という指摘はすべて、結論ではなく、そのシステムを知る人への質問として扱ってください。

まずどこから

リージョンをひとつ、本番のVPCをひとつ選びます。グループ、規則、紐づくインスタンスを書き出し、意図する方針を平易な五文で書き、背後にあるものの順に並べた広すぎる規則の一覧を求めます。短い一覧が返り、その多くは見覚えがあり、いくつかはありません。世界に開いた管理用ポートから、通常の変更手続きを通して直し、書き出しは戻し方として保管します。そして来月それを回すのが誰かを決めてください。一度の掃除は、誰も覚えていなくてよい輪よりずっと価値が低いからです。その輪を、監査が求める証跡つきできちんと担ってほしいなら、お問い合わせください。