クラウドセキュリティエンジニアを業務委託で確保する方法｜見極めと権限設計

取引先から届いたセキュリティチェックシートに「クラウド環境の権限管理体制」という欄を見つけて、手が止まってしまった経験はないでしょうか。社内監査で「本番環境に誰がアクセスできるのか、一覧で出せますか」と聞かれ、その場で答えられなかったという方もいるかもしれません。クラウド移行を終えた企業では、こうした場面をきっかけに専門人材の必要性を認識するケースが珍しくありません。

ところが正社員での採用は簡単ではありません。募集をかけても応募が集まらず、上長からは「外部でもいいから早く手当てしてほしい」と言われている状況では、業務委託への方針転換は現実的な選択肢に見えます。それでも稟議書を書き始められない理由が、多くの場合ひとつあります。外部の人に、本番クラウドの管理者権限を渡すことになるという点です。

セキュリティを強化するために呼んだ人に、社内で最も強い権限を渡さなければなりません。クラウドでは管理者権限がそのまま全リソースへのフルアクセスを意味しうるため、この矛盾はオンプレミス環境の委託よりも切実です。しかも社内にクラウドセキュリティの知見がないので、相手のスキルを見極める質問すら作れません。委託がかえってリスクを増やすのではないか、という不安は当然のものです。

しかし、この不安は「権限を渡すかどうか」ではなく「どう渡すか」を設計することで大きく減らせます。委託範囲を責任共有モデルから逆算して決め、権限の粒度と有効期限を先に決め、操作ログの取得と契約終了時の失効手順を契約条件に書き込む。これらは技術者でなくても、発注者の立場で決められる事柄です。

本記事では、クラウドセキュリティエンジニアを業務委託で確保する手順を、発注する側の視点で順に整理します。委託できる業務範囲の分解、責任共有モデルを使った委託範囲の切り分け、フリーランス・SES・受託ベンダーの調達ルート比較、資格に頼らないスキル見極めの質問、準委任契約での発注条件、そして最大の論点である外部人材への権限設計と、委託終了後に運用を社内へ残す進め方までを扱います。読み終えたときに、募集要項と稟議書の骨子が書ける状態を目指します。

クラウドセキュリティエンジニアを業務委託で確保する企業が増えている理由

「本当は正社員で採りたい」という前提から出発している方は多いはずです。まず、その前提を一度点検しておきます。業務委託への切り替えが妥協ではなく合理的な判断になりうる理由を、採用市場の構造とクラウド固有の事情の 2 つに分けて確認します。

セキュリティ人材の採用が成立しにくい構造

セキュリティ人材の不足は、自社だけの問題ではありません。MM総研が国内企業でシステム・端末の選定に関わるサイバーセキュリティ担当者 1,000 人に対して実施した調査では、82% の企業がセキュリティ人材の不足を認識しているという結果が出ています。同じ調査で、26% の企業が外部委託を拡大していることも報告されています（MM総研「民間企業におけるサイバーセキュリティ対策の動向調査」2025年9月発表）。

国レベルでも同様の認識が示されており、国内のサイバーセキュリティ人材は約 11 万人不足しているという民間調査結果が政策文書で引用されています（出典: 経済産業省「サイバーセキュリティ人材の育成促進に向けた検討会 最終取りまとめ」2025年5月）。つまり「募集をかけたが半年間応募がなかった」という状況は、募集内容が悪かったからというより、市場全体の需給がそうなっているためと考えるのが自然です。

さらに、従業員 100〜300 名規模の企業ではもうひとつの制約があります。クラウドセキュリティの専任者を 1 名採用しても、その人が退職した瞬間に体制がゼロに戻るという点です。専任 1 名体制は、採用の難しさに加えて属人化のリスクも同時に抱えます。「常時 1 名を抱える」のではなく「必要な範囲に必要な稼働だけを充てる」という発想に切り替えると、業務委託は現実的な選択肢として立ち上がってきます。

クラウド移行で必要なスキルが変わった

「社内のインフラ担当に兼務させればよいのでは」という案は、多くの企業でまず検討されます。ここで確認しておきたいのが、クラウド移行によってセキュリティに求められるスキルセットが変質したという点です。

オンプレミス環境では、セキュリティ対策の中心はネットワーク境界の防御でした。ファイアウォールを設置し、外部からの通信を遮断し、物理的なサーバールームへの入退室を管理していました。守るべき境界が、物理的に見える形で存在していたわけです。

クラウドでは、この境界が設定情報に置き換わります。ストレージの公開設定を 1 か所変えるだけでデータが全世界に公開されうるし、権限ポリシーを 1 行広げるだけでアクセス範囲が一気に広がります。求められるスキルは「機器を設置して守る」から「設定・権限・ログを設計し、それが意図どおりであり続けることを継続的に確認する」へと移りました。

この変化の重さは、脅威の統計にも表れています。IPA が公表した「情報セキュリティ10大脅威 2026」の組織編では、2 位に「サプライチェーンや委託先を狙った攻撃」が挙げられています（IPA「情報セキュリティ10大脅威 2026」）。委託先経由の侵入が主要な脅威として位置づけられているという事実は、これから外部人材に権限を渡そうとしている立場からすると重い意味を持ちます。委託そのものが新しい攻撃面になりうるからです。

だからこそ、業務委託を進めるうえで必要なのは「頼れる人を探すこと」だけではありません。何を頼み、どこまでの権限を、どういう条件で渡すかを先に設計することが、外注の成否を分けます。以降のセクションでは、その設計を順に組み立てていきます。

クラウドセキュリティエンジニアとは｜インフラエンジニア・情報セキュリティ担当との業務範囲の違い

募集要項や発注書を書くには、まず「クラウドセキュリティエンジニアに何を任せられるのか」を自分の言葉で説明できる必要があります。ここでは職種紹介ではなく、発注条件に転記できる粒度で業務範囲を分解します。

業務範囲を 4 領域に分解する

クラウドセキュリティエンジニアの担当領域は、大きく次の 4 つに分けて考えると整理しやすくなります。

この 4 領域は、必ずしも 1 人にまとめて任せる必要はありません。設計だけを短期で依頼し、運用は社内に残すという組み合わせも成立します。この分解が、後述する委託範囲の切り分けと調達ルートの選択の土台になります。

なお、求職者向けの記事でよく見かける「年収」「キャリアパス」といった情報は、発注者の判断にはほとんど使えません。参考にすべきは業務範囲の定義のほうです。

インフラエンジニア／情報セキュリティ担当／SOC アナリストとの境界

「うちのインフラエンジニアでは足りないのか」「情報セキュリティ担当を採ればよいのでは」という疑問に答えるため、隣接する職種との重なりと違いを整理します。

この表から読み取れることが 2 つあります。

ひとつは、インフラエンジニアとクラウドセキュリティエンジニアは「重なるが同じではない」という点です。クラウド環境を構築できることと、その構成が脅威に対して妥当かを評価できることは別のスキルです。「うちのインフラ担当に兼務させる」という案が機能しにくいのは、能力の問題ではなく、必要な知識体系が異なるためです。

もうひとつは、社内の情報セキュリティ担当は代替ではなく相方になるという点です。規程の整備・監査対応・全社への周知は社内側の役割であり、そこにクラウド固有の技術的裏づけを供給するのが委託人材の役割になります。この分担を最初に決めておくと、委託の目的がぶれにくくなります。

業務委託の範囲は責任共有モデルから逆算して決める

委託範囲を決める作業は、白紙から考えると途方もなく感じられます。しかし、クラウドには「どこからが利用企業の責任か」を定義した既存の枠組みがあります。責任共有モデルです。これを説明のための図としてではなく、委託範囲を切り出すための道具として使います。

責任共有モデルで自社の責任範囲を書き出す

責任共有モデルは、クラウド事業者が「クラウドのセキュリティ」を、利用企業が「クラウド内のセキュリティ」を担うという分担を定めたものです。AWS はデータセンターの物理セキュリティ、ハードウェア、仮想化基盤などを担当し、利用企業は OS やアプリケーションの設定、データの暗号化、ネットワークやファイアウォールの設定、そしてアカウントとアクセス権限の管理を担当します（AWS「責任共有モデル」）。Azure でも同様の考え方が示されており、SaaS・PaaS・IaaS のどれを使うかによって利用企業側の責任範囲が変動する点が明示されています（Microsoft「クラウドにおける共同責任」）。

最初の作業は、この「利用企業側」に属する項目を自社の環境に当てはめて書き出すことです。難しく考える必要はなく、次のような粒度で構いません。

• クラウドアカウント（AWS アカウント / Azure サブスクリプション）はいくつあり、誰が管理しているか
• 本番環境にアクセスできる利用者は誰か。管理者権限を持っているのは何人か
• 外部に公開されているストレージ・エンドポイントはあるか。それは意図したものか
• 操作ログ（誰がいつ何をしたか）は取得されているか。保管期間はどれくらいか
• 保存データの暗号化と鍵の管理は誰が行っているか
• 設定変更のレビュー・承認の手続きはあるか

書き出せない項目があっても問題ありません。書き出せない項目こそ、委託して最初に棚卸ししてもらうべき対象です。この一覧はそのまま募集要項の「現状」欄と、初期フェーズの作業依頼内容になります。

委託する領域・社内に残す領域の線引き（丸投げできない 3 項目）

利用企業側の責任範囲を書き出したら、次はそれを「委託する」「社内に残す」に振り分けます。ここで重要なのは、責任共有モデルにおける利用企業の責任は、業務を委託しても移転しないという点です。設定を誤ったのが委託先であっても、利用者や取引先に対して説明責任を負うのは自社です。

したがって、以下の 3 項目は委託の対象外とし、社内に残すことを前提に設計してください。

1. リスク受容の意思決定 「この脆弱性は業務影響を考慮して当面受容する」「この設定は利便性を優先して例外扱いにする」といった判断は、事業リスクの引き受けそのものです。委託先は選択肢とトレードオフを提示できますが、決めるのは発注側です。この線引きを曖昧にすると、後から「なぜその設定になっていたのか」を誰も説明できなくなります。

2. 情報資産の棚卸しと重要度の判定 どのデータが最も重要か、どのシステムが止まると事業が止まるかは、事業を運営している側にしか判断できません。委託先は技術的な保護策を設計できますが、「何を最優先で守るか」の入力がなければ設計の優先順位を決められません。

3. インシデント発生時の対外報告の判断 個人情報漏えいの可能性が生じた場合、監督官庁への報告・本人への通知・取引先への連絡をいつどう行うかは経営判断です。委託先は技術的な調査結果を提供する立場であり、報告の実行主体にはなりません。この点は、後述する契約条件でも明示しておく必要があります。

逆に言えば、この 3 項目以外の技術的な設計・構築・運用の実務は、業務委託の対象として切り出せます。

人材の業務委託とマネージドサービス（MSS/SOC）はどちらを選ぶか

クラウドセキュリティの外注には、大きく 2 つの形があります。「人を確保する」形と「サービスを買う」形です。両者は代替関係ではなく、適する場面が異なります。

判断の目安はシンプルです。「設定と権限を整える」段階なら人材の業務委託、「整った環境を継続監視する」段階ならマネージドサービスが向いています。現状把握もできていない段階でいきなり 24 時間監視サービスを契約すると、大量のアラートが届いても社内で判断できず、費用だけがかかる状態になりがちです。

両者を組み合わせる場合も、順序としては設計・構築を先に済ませ、運用の一部を後からサービスに寄せる流れが現実的です。判断基準や費用感をより詳しく比較したい方は、セキュリティエンジニア外部委託の判断基準と費用相場で内製採用・MSS との選び方を整理しています。

調達ルートの比較｜フリーランス・SES・受託ベンダーのどこでクラウドセキュリティ人材を確保するか

委託範囲が決まったら、次は「どこで探すか」です。ルートによってリードタイム・稼働の柔軟性・社内に残る知見の量が変わるため、範囲とルートは対応させて考える必要があります。

4 つの調達ルートの比較表

比較の軸として見落とされがちなのが「知見の社内蓄積」です。委託が終わった後にまた誰も見られない状態へ戻るかどうかは、ルート選択の段階である程度決まります。個人に業務委託して社内担当と並走してもらう形は、この観点では有利です。

委託範囲別の推奨ルート

先ほど整理した 4 領域（設計・構築・運用・インシデント対応）と、委託範囲の組み合わせごとに、適合しやすいルートを示します。

現状把握と設計だけを依頼したい場合 権限の棚卸し、設定不備の洗い出し、あるべき権限設計の策定までを 1〜3 か月で区切る依頼です。フリーランスへの業務委託が適合しやすく、週 1〜2 日の稼働でも成立します。成果物（棚卸し結果・設計書・改善計画）を明示して発注するとスコープがぶれません。

設計から構築、継続運用までを任せたい場合 ガードレールの実装、CSPM の導入、定期的な権限棚卸しまで含む依頼です。週 2〜3 日程度の継続稼働が必要になるため、フリーランスへの業務委託か SES が候補になります。運用フェーズでは社内担当を並走させ、手順書を残してもらう前提で契約すると、後の引き継ぎが楽になります。

インシデント対応まで含めたい場合 24 時間の検知・初動が求められる場合、個人の業務委託では対応時間の保証が難しくなります。この領域は MSS / SOC などのサービスと組み合わせるのが現実的です。ただし、サービス側から上がってきた検知を「自社にとって何を意味するか」に翻訳する役割は必要なので、人材の業務委託と併用する構成がよく取られます。

稼働日数と単価の考え方

予算稟議を通すには、金額の根拠が必要です。ここで押さえておきたいのは、クラウドセキュリティの委託はフル稼働を前提にしなくてよいという点です。

設計・棚卸し・改善計画といった業務は、まとまった時間を確保できれば週 1〜2 日でも進みます。継続運用フェーズでも、アラートの一次判断とレビューが中心であれば週 2〜3 日で回るケースがあります。「専任 1 名分の人件費」を前提に見積もると、必要以上に大きな金額になり稟議が通りにくくなります。

稟議書に書くべきは、次の 3 点をセットにした根拠です。

1. 委託する業務範囲（4 領域のうちどこか、具体的な成果物は何か）
2. 想定稼働（週何日 × 何か月か）
3. その期間で達成する状態（例: 権限棚卸しの完了、公開設定の是正、CSPM 導入と月次レポートの運用開始）

金額レンジそのものについては、調達ルート別の相場観をセキュリティエンジニア外部委託の判断基準と費用相場にまとめています。本記事では金額の詳細には立ち入らず、次のスキル見極めに進みます。

スキルの見極め方｜資格の読み方と、知見がなくても使える確認質問

社内にクラウドセキュリティの知見がない状態で、候補者のスキルをどう見極めるか。これは業務委託を検討する担当者が最も詰まりやすい論点です。ここでは、資格の読み方と、専門知識がなくても使える確認質問を用意します。

主要資格が保証する範囲と保証しない範囲

資格は判断材料のひとつですが、それだけで委託先を決められるものではありません。何を保証し、何を保証しないかを整理しておきます。

読み取り方の要点は 2 つです。

第一に、資格は「知識の体系性」を保証しますが「実務経験」は保証しません。 CISSP のように実務経験を受験要件に含むものもありますが、その経験がクラウドの権限設計であるとは限りません。

第二に、ベンダー資格とベンダー中立資格では意味が異なります。 AWS Certified Security - Specialty は AWS の具体的なサービス知識を示す一方、CCSP はクラウド全般の設計思想やガバナンスの知識を示します。自社が AWS 単一なのかマルチクラウドなのかによって、重視すべき資格は変わります。

したがって実務上は、「資格の有無で足切りする」のではなく「資格を入口に、実務経験を質問で確認する」進め方をおすすめします。

面談でそのまま使える実務確認質問（5 系統）

以下は、クラウドセキュリティの専門知識がなくても読み上げられる質問です。回答の技術的正しさを判定する必要はありません。具体的なエピソードが返ってくるかどうかを見るだけで、実務経験の有無はかなり判別できます。

系統1: 権限設計の経験

• 「これまでに、本番環境のアクセス権限を設計または見直した経験を教えてください。どのような体制で、どこまでの範囲を担当されましたか」
• 「管理者権限を持つ利用者を減らす取り組みをされたことはありますか。そのとき、現場からどのような反発があり、どう調整されましたか」

系統2: ログの設計と保全

• 「操作ログの取得と保管について、設計に関わった経験を教えてください。保管期間はどのように決めましたか」
• 「ログを調査に使った場面はありますか。そのとき、必要な情報が取れていた／取れていなかった経験を教えてください」

系統3: 設定監視（CSPM 等）の運用

• 「クラウドの設定監視ツールを導入した経験はありますか。導入直後に大量に出た検出項目を、どういう基準で優先順位づけしましたか」
• 「検出されたが対応しないと判断した項目について、その判断をどう記録・共有しましたか」

系統4: インシデント対応の経験と対外的な関わり方

• 「セキュリティインシデントの対応に関わった経験を、差し支えない範囲で教えてください。ご自身はどの役割を担当されましたか」
• 「そのとき、お客様や監督官庁への報告について、どこまで関与されましたか」

系統5: 自動化・IaC でのガードレール実装

• 「セキュリティ設定をコード（IaC）で管理した経験はありますか。人が手で変更できないようにする仕組みを入れたことはありますか」
• 「設定が意図せず変更されたことを検知する仕組みを作った経験を教えてください」

これらに加えて、発注側の状況を率直に伝えたうえでの質問も有効です。「当社にはセキュリティ専任がおらず、体制をゼロから作る状況です。最初の 1 か月で何から着手しますか」と聞けば、相手が現場をどう見立てるかが分かります。

回答から何を読み取るか

技術的な正しさを判定できなくても、回答の性質から読み取れることがあります。

特に注目したいのが「発注側への確認姿勢」です。委託後に丸投げ状態を防げるかどうかは、相手が発注側の意思決定を求めてくるかどうかに表れます。先に整理した「社内に残す 3 項目」を相手が自然に発注側へ返してくるなら、健全な分担が期待できます。

契約形態と発注条件の固め方｜準委任契約でスコープと責任を明確にする

見極めができたら、次は契約です。セキュリティ業務は「何をもって完成とするか」を定義しにくい領域のため、契約形態の選択と発注条件の書き方が、後のトラブルの有無を大きく左右します。

準委任契約と請負契約のどちらを選ぶか

請負契約は「仕事の完成」に対して報酬を支払う契約で、受注側は完成義務を負います（民法第 632 条）。一方、準委任契約は法律行為以外の事務の委託であり、受注側は善管注意義務を負って業務を遂行しますが、成果の完成そのものを約束するわけではありません（民法（e-Gov 法令検索））。準委任契約はさらに、稼働量に応じて報酬を支払う「履行割合型」と、成果物の引き渡しに対して支払う「成果完成型」に分かれます。

クラウドセキュリティの委託業務では、継続的な設計・運用支援は準委任契約（履行割合型）、成果物が明確な単発作業は準委任契約（成果完成型）または請負契約という使い分けが実務的です。

判断の目安を整理します。

「セキュリティを万全にする」といった完成義務を請負契約で負わせようとしても、そもそも達成基準を定義できないため、実務上は機能しません。完成義務を負わせる代わりに、遂行すべき業務内容と報告義務を具体的に書き込むほうが、双方にとって運用しやすい契約になります。

発注条件に必ず書き込む項目（チェックリスト）

契約書または発注条件書に盛り込むべき項目を、クラウドセキュリティ委託に固有の観点を含めて整理します。

• 作業範囲: 4 領域（設計・構築・運用・インシデント対応）のうちどこを含むか。含まない領域も明記する
• 成果物: 納品するドキュメント（設計書・棚卸し結果・手順書・運用レポート）とその形式
• 報告頻度と形式: 定例の頻度、レポートの内容、緊急時の連絡手段
• アクセスを許可する範囲: どのアカウント・どの環境（本番／検証）へのアクセスを許可するか
• 権限の付与条件: 誰が承認して権限を付与するか、有効期限を設けるか（詳細は次のセクション）
• 秘密保持: 対象情報の定義、契約終了後の存続期間、返却・破棄の方法
• 再委託の可否: 可とする場合、事前承諾の要否と再委託先への義務の承継
• 持ち込み機材・作業環境: 委託先の PC を使うのか、貸与端末を使うのか
• インシデント発生時の役割: 委託先が担う技術的作業と、発注側が担う判断・報告の分担
• 契約終了時の手続き: アカウントの失効、データの返却・破棄、引き継ぎ資料の提出

このうち「秘密保持」「再委託の可否」「アクセス制限」といった条項を、契約書の文言としてどう書くかについては、システム開発の外注契約で押さえる情報セキュリティ条項チェックリストで条項レベルの解説をしています。本記事では「何を決めるか」に絞り、条文の書き方はそちらに譲ります。

インシデント発生時の責任分担と連絡経路をあらかじめ決めておく

インシデントが起きたとき、最も時間を失うのは「誰が何を決めるのか分からない」状態です。委託を始める前に、次の 3 点だけでも文書化しておくと初動が変わります。

1. 検知から連絡までの経路 委託先が異常を検知した場合、誰に何分以内に連絡するか。発注側の一次受け（担当者と代理者）を氏名レベルで決めておきます。夜間・休日の扱いも明記します。

2. 委託先が独断でできる作業の範囲 「明らかな不正アクセスを検知した場合、該当アカウントの無効化は事前連絡なしで実施してよい」といった緊急時の裁量を、あらかじめ与えておくかどうかを決めます。裁量を与えない場合、深夜の判断待ちで被害が広がる可能性があります。逆に無制限に与えると、業務停止の判断まで委託先が負うことになります。範囲を区切って合意しておくのが現実的です。

3. 対外報告の主体 先に述べたとおり、監督官庁への報告・本人通知・取引先への連絡は発注側が主体となります。委託先の役割は技術的な調査結果と時系列の提供であることを、契約段階で相互に確認しておきます。

外部人材にクラウド権限を渡す設計｜最小権限とアカウントのライフサイクル

ここが、業務委託に踏み切れない最大の理由に直接答えるセクションです。「外部の人に管理者権限を渡すのが怖い」という感覚は正当です。答えは「渡さない」ではなく「渡し方を設計する」ことにあります。技術的な実装は委託先が担いますが、何を決めるかは発注側が主導できます。

「とりあえず管理者権限」が生むリスク

外部人材の受け入れ時に最も多い進め方が、「作業が止まると困るのでとりあえず管理者権限を付与する」というものです。この判断には 3 つの問題があります。

第一に、権限の広さと作業の必要範囲が一致しません。 クラウドの管理者権限は、権限の変更・請求情報の閲覧・全リソースの削除を含むことがあります。設定の棚卸しをするだけなら、本来は読み取り権限で足ります。

第二に、事故の影響範囲が広がります。 悪意の有無に関わらず、操作ミスひとつで本番環境のリソースを削除できる状態は、委託先にとってもリスクです。強すぎる権限は、受け取る側にも心理的な負担をかけます。

第三に、権限を後から絞るのは難しくなります。 一度広い権限で作業が回り始めると、「絞ると業務が止まるかもしれない」という懸念から縮小の判断が先送りされます。契約終了時にアカウントが残り続ける事態も、この延長線上で起きます。

クラウド事業者自身も、必要な権限だけを付与する最小権限の原則を推奨しています（AWS「IAM でのセキュリティのベストプラクティス」）。特別に厳しい要求ではなく、標準的な運用として位置づけられている考え方です。

最小権限で始めるための 4 つの決めごと

発注側が決めるべきことは、次の 4 点に集約できます。技術的な実装方法は委託先に任せてよく、決定事項として提示すれば足ります。

1. 権限の粒度 — 読み取りから始める 初期フェーズ（現状把握・棚卸し）は読み取り専用の権限で開始します。変更が必要になった時点で、対象範囲を限定した権限を追加します。「まず読み取り専用から始めたい」と伝えて難色を示す委託先は、進め方の面でも注意して確認したほうがよいでしょう。

2. 有効期限 — 恒久的な権限を作らない 権限には期限を設けます。AWS の場合、恒久的なアクセスキーを発行する代わりに、一時的な認証情報を発行する IAM ロールを使う方法があります。委託先の環境からロールを引き受ける形にすると、権限の切り離しは信頼関係の設定を変更するだけで済みます。第三者にアクセスを許可する場合の設計については、外部 ID を用いる方法が公式に案内されています（AWS「サードパーティーに AWS リソースへのアクセスを許可するときに外部 ID を使用する」）。Azure でも、必要なときだけ権限を有効化する仕組みが提供されています（Microsoft「Privileged Identity Management の構成」）。

3. 多要素認証 — 例外を作らない 外部からアクセスするアカウントには多要素認証を必須にします。委託先が複数名になる場合も、アカウントの共用は避け、1 人 1 アカウントを原則とします。共用アカウントは「誰が操作したか」を追跡できなくするため、後述するログの価値を大きく損ないます。

4. 承認者 — 権限付与を誰が決めるか 権限の追加を誰が承認するかを、社内で 1 人（と代理者 1 人）に固定します。委託先の申請に対して、発注側の誰かが必ず内容を確認して承認する流れにしておくと、権限が知らないうちに広がる事態を防げます。この承認記録は、取引先のセキュリティチェックシートや社内監査への回答材料としても使えます。

これら 4 点を発注条件に書き込むだけで、「管理者権限をそのまま渡す」以外の選択肢が具体化します。

操作ログの取得と、契約終了時のアカウント失効手順

権限を絞ったうえで、次に必要なのが「どのような操作が行われたか」を後から確認できる状態です。

操作ログの取得と保管 クラウドの API 操作履歴を記録する仕組みは、主要なクラウドで標準的に提供されています。AWS であれば CloudTrail が該当し、アカウントで行われたアクションを記録します（AWS「AWS CloudTrail ユーザーガイド」）。発注側が決めるべきは次の 3 点です。

• ログを取得しているか（取得していない場合は、委託の初期フェーズで有効化を依頼する）
• 保管期間をどれくらいにするか（インシデントの発覚が遅れる可能性を踏まえて設定する）
• 委託先がログ自体を削除・改変できない状態になっているか

3 点目は見落とされがちですが重要です。監査の観点では、操作する人とログを管理する人を分けることが望まれます。ログの保管先を委託先が変更できない構成にしておけば、後から履歴を検証できます。

利用状況の定期確認 付与した権限が使われているかを定期的に確認します。AWS には、権限が最後に使用された日時を確認できる機能があり、使われていない権限の削除判断に利用できます（AWS「IAM で最終アクセス情報を使用してアクセス許可を絞り込む」）。四半期ごとの棚卸しを運用に組み込んでおくと、権限が肥大化しません。

契約終了時の失効手順 契約終了・稼働終了時に実施することを、あらかじめ手順として決めておきます。以下の項目を発注条件に含め、実施の責任者（発注側の誰か）を明記します。

1. 委託先アカウントの無効化・削除（終了日当日中に実施）
2. 発行した認証情報・アクセスキーの失効
3. ロールの信頼関係設定から委託先アカウントを削除
4. 共有していた認証情報がある場合は再発行（本来は共有しないことが前提）
5. 貸与端末・資料の返却、および委託先環境に保存されたデータの破棄確認
6. 失効の完了報告を書面で受領

「契約は終わったがアカウントは残っている」という状態は、監査で必ず指摘される事項です。契約開始時に終了手順を決めておくことで、担当者の異動があっても手順が残ります。

ここまでの決めごとを整理すると、外部人材への権限付与は「怖いから渡さない」でも「必要だから全部渡す」でもなく、粒度・期限・認証・承認・記録・失効の 6 点を設計する作業に変わります。この設計は、発注側が主導できるものです。

委託後に運用が社内に残る進め方｜オンボーディングと引き継ぎ

最後の論点は、「委託が終わったら、また誰も見られない状態に戻るのではないか」という不安です。これは進め方の設計で相当程度まで回避できます。ここでは参画後 30 日・90 日の目安と、引き継ぎ成果物の定義を扱います。

最初の 30 日で棚卸しすること

参画直後にいきなり対策の実装へ進むと、優先順位の根拠がないまま作業が始まります。最初の 30 日は現状把握に充てるのが定石です。具体的には、次の 4 つの棚卸しを成果物として依頼します。

1. アカウント・環境の棚卸し クラウドアカウント（サブスクリプション）の一覧、それぞれの用途、本番／検証の区別、請求の紐づけを整理します。「把握していないアカウントがあった」というケースは珍しくありません。

2. 権限の棚卸し 誰がどの環境にアクセスできるか、管理者権限の保有者は誰か、退職者・異動者のアカウントが残っていないかを一覧化します。この一覧は、取引先のセキュリティチェックシート回答にもそのまま使えます。

3. 公開設定の棚卸し インターネットから到達可能なリソース（ストレージ、エンドポイント、管理コンソールへのアクセス経路）を洗い出し、意図したものかを確認します。

4. ログの取得状況の棚卸し 操作ログ・アクセスログが取得されているか、保管期間はどれくらいか、調査に使える状態かを確認します。

そのうえで、明らかな設定不備（意図しない公開設定、使われていない管理者権限、多要素認証が未設定のアカウントなど）については、この期間中に是正まで進めると成果が可視化されます。発注側にとっても、最初の 30 日で「何が分かって、何が直ったか」が見える状態になることが、契約継続の判断材料になります。

90 日で運用に載せること

30 日で現状が見えたら、次の 60 日は「継続的に確認できる状態」を作るフェーズです。

設定監視の仕組み化（CSPM の導入と運用設計） CSPM（Cloud Security Posture Management）は、クラウドの設定内容を継続的にチェックし、不適切な設定を検出する仕組みです。設定が意図せず変更されたり、新しいリソースが安全でない状態で作られたりしたことを、人の目視ではなく自動で拾えるようにします。

ただし、導入しただけでは機能しません。導入直後は検出項目が大量に出るため、運用設計のほうが本体です。発注側として決めておきたいのは次の 3 点です。

• 検出項目の優先度をどう分類するか（即時対応・計画的対応・受容の 3 段階など）
• 「受容」と判断した項目を、誰の承認でどこに記録するか
• 誰がアラートを一次確認し、どのタイミングで発注側にエスカレーションするか

3 点目が抜けると、委託先が全部見てくれていると発注側は思い、発注側が判断すると委託先は思う、という空白が生まれます。

定期棚卸しと定例報告の型を作る 四半期ごとの権限棚卸し、月次の運用レポートといった定期業務の型を、この期間で確立します。レポートの項目（検出件数・対応件数・未対応の理由・次月の予定）を固定しておくと、担当者が交代しても継続できます。

社内担当の並走 この期間中、社内のインフラ担当や情報システム担当を並走させます。すべてを理解する必要はなく、「アラートが来たときにどう見るか」「誰に連絡するか」が分かる程度で十分です。並走の時間を確保するには、委託先の稼働と社内担当の稼働を両方見込んでスケジュールを組む必要があります。

引き継ぎ用の成果物を契約時に定義しておく

委託終了後に運用が残るかどうかは、契約時に成果物として何を定義したかでほぼ決まります。「引き継ぎもお願いします」という口頭の合意では、ドキュメントの粒度が担当者の裁量に委ねられます。

契約書または発注条件に、次の成果物を明記することをおすすめします。

とりわけ「受容リスク一覧」は、社内に残す価値が高い成果物です。何を直したかよりも、何を直さないと決めたのかが失われやすく、担当者交代のたびに同じ議論が繰り返されるためです。

なお、クラウド権限に限らず、外部人材の情報管理ルール全般（貸与端末の扱い、データの持ち出し制限、入退場の手続きなど）を整備したい場合は、業務委託エンジニアのセキュリティ教育で仕組み化の手順を解説しています。

まとめ｜クラウドセキュリティエンジニアの業務委託を進める順序

ここまでの内容を、着手する順序として整理します。上から順に進めれば、募集要項と稟議書の骨子が書ける状態になります。

ステップ1: 委託範囲を決める 責任共有モデルを使って自社側の責任範囲を書き出し、設計・構築・運用・インシデント対応の 4 領域のうちどこを委託するかを決めます。リスク受容の意思決定・情報資産の重要度判定・対外報告の判断の 3 項目は社内に残します。

ステップ2: 調達ルートを選ぶ 委託範囲に応じて、フリーランスへの業務委託・SES・受託ベンダー・マネージドサービスから選びます。「設定と権限を整える」段階なら人材の業務委託、「整った環境を継続監視する」段階ならサービスが向いています。

ステップ3: スキルを見極める 資格は入口として扱い、権限設計・ログ設計・設定監視の運用・インシデント対応・自動化の 5 系統について実務経験を質問で確認します。技術的な正しさではなく、回答の具体性・トレードオフの認識・発注側への確認姿勢を見ます。

ステップ4: 契約とスコープを固める 継続的な支援は準委任契約（履行割合型）、成果物が明確な作業は成果完成型または請負契約を選びます。作業範囲・成果物・報告頻度・秘密保持・再委託の可否・インシデント時の役割・契約終了時の手続きを発注条件に書き込みます。

ステップ5: 権限設計を決める 粒度（読み取りから始める）・有効期限（恒久的な権限を作らない）・多要素認証（例外を作らない）・承認者（1 人に固定）の 4 点を決め、あわせて操作ログの取得・保管と、契約終了時の失効手順を定めます。

ステップ6: オンボーディングと引き継ぎを設計する 最初の 30 日を棚卸しに充て、90 日で設定監視と定例報告の運用を確立します。権限設計書・運用手順書・判断記録・受容リスク一覧・レポートテンプレートを成果物として契約時に定義し、委託終了後も社内で運用が続く状態を作ります。

外部人材にクラウドの権限を渡すことは、確かにリスクを伴います。ただ、そのリスクは「渡すか渡さないか」で管理するものではなく、渡す範囲・期限・記録・失効を設計することで管理するものです。設計は発注側が主導でき、その設計内容はそのまま、取引先のセキュリティチェックシートや社内監査への回答材料にもなります。まずは自社の責任範囲の書き出しから着手してみてください。

関連情報

外部人材の受け入れ体制や進捗の見える化、引き継ぎ設計まで含めて整理したい方は、業務委託エンジニアのマネジメント実践ガイド をご参照ください。社内で発注条件を検討する際のたたき台としてお使いいただけます。

クラウド環境のセキュリティ体制づくりや、外部人材の受け入れ設計についてご相談がある方は、お問い合わせフォーム からご連絡ください。要件が固まっていない段階からのご相談にも対応しています。