クラウドの権限管理の案件では、渡す範囲を先に決めます

📘 この記事でわかること
- クラウドサービスの利用開始時に権限の範囲を先に決めておくことと、選ぶときと運用するときで確認ポイントが分かれていること
- 権限を人にではなく役割に対応させる考え方と、管理担当者に「特性を理解した」人が条件になっていること
- ID・パスワードを共有しない認証の確認項目と、実際に起きた2つの事故で原因が異なっていたこと
クラウドサービスを導入する場面では、権限の設計より先にIDの発行が進むことがあります。誰にどこまでの権限を与えるかを後から絞り込むのは難しく、確認しておくべき点を見落としたまま運用が始まりがちです。中小企業向けの手引きは、クラウドサービスを安全に利用するための確認事項と注意点を示しています1。ここでは、選ぶ場面と運用する場面で分かれている確認ポイントを、権限管理の観点から整理します。
1. 渡す範囲は、後から絞るより先に決めます
確認ポイントは「選ぶとき」と「運用するとき」に分かれています
クラウドサービスの導入を検討する段階では、機能や料金の比較に目が向きやすくなります。しかし手引きが示す確認事項は、選ぶ場面と運用する場面の両方にまたがっています1。クラウドサービスのセキュリティは、事業者と利用者が役割・責任を分担して維持・向上させる関係にあり、どちらか一方の対策で対策が完結するものではありません2。導入前の比較検討だけを済ませて安心してしまうと、運用が始まってから確認すべき点が抜け落ちたまま進んでしまいます。
クラウドサービス安全利用チェックシートは、選択するときの確認ポイントを6項目、運用するときの確認ポイントを4項目という構成で示しています4。権限をどこまで渡すかは、この運用側の確認ポイントに含まれる論点です。選ぶ段階で決め切れなかった範囲を、運用が始まってから絞り込もうとすると、すでに付与した権限を後から回収する作業が発生します。
クラウドの権限管理に関わる案件では、この「選ぶとき」と「運用するとき」のどちらの局面を担当するかによって、求められる仕事の中身が変わります。選ぶ段階では、業務要件を整理し、確認ポイントに沿ってサービスや設定を比較検討する作業が中心になります。運用段階では、すでに動いている権限の構成を点検し、必要に応じて見直す作業が中心になります。案件の内容を確認するときは、どちらの局面を主に担当することになるのかを見極めることが役に立ちます。
2つの局面で、担当する作業の粒度が変わります
選ぶときの確認は、複数の候補を並べて比較する作業になりやすく、資料やヒアリングをもとにまとめる粒度の仕事です。運用するときの確認は、すでにある設定を1つずつ点検し、必要な箇所だけを直していく粒度の仕事になります。同じ「クラウドの権限管理」という言葉でも、案件によって担当する粒度がこれだけ変わることは、業務の依頼内容を読み解くうえで見落とされがちです。
どちらの粒度の仕事であっても、確認する項目そのものは手引きに沿っています。違うのは、確認を「まとめる」段階にいるのか、「直す」段階にいるのかという立ち位置です。
出典:独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」(2026年6月)をもとに作成
手引きが選ぶときと運用するときを分けているのは、確認を一度で終わらせない設計だといえます。導入時に済ませたつもりの確認が、運用が進むにつれて古くなることも珍しくありません。担当者の入れ替わりや、利用する機能の追加によって、当初の想定と実態がずれていくためです。定期的に見直す前提を持っておくことが、この構成から読み取れます。
次の章では、運用の確認ポイントに含まれる権限を、どのように割り振っていくかを見ていきます。
2. 権限は人ではなく役割に対応させます
承認権限を「役割」に結び付ける書き方
権限を配るとき、氏名のリストを一人ずつ確認していく運用は手間がかかります。手引きが挙げる運用の確認ポイントには、サービスが必要なのは誰か、誰にどのような権限を与えるかを決めることが含まれ、承認権限は管理職に付与するという書き方が例として示されています5。権限は、名前を管理する仕組みではありません。むしろ役割に対応させる仕組みです。氏名のリストで権限を管理していると、確認するたびに現在の担当者を調べ直す作業が発生します。
名前で覚える権限よりも、役割で決める権限のほうが、担当者が入れ替わっても設定を一から見直す必要が生じにくくなります。個人ではなく役割に権限を対応させておけば、誰が承認権限を持つべきかという問いにも、資料に示された考え方で答えられます。
| 権限の種類 | 対応させる役割 | 資料が示す考え方 |
|---|---|---|
| 承認権限 | 管理職 | 承認権限は管理職に付与するという書き方が例として示されています5 |
| 利用の可否 | 業務でサービスを必要とする担当者 | サービスが必要なのは誰かを確認する考え方が示されています5 |
| 権限全体の管理 | 特性を理解した管理担当者 | 管理担当者を社内に確保することが確認ポイントに含まれています6 |
役割ごとに権限を定義しておくと、新しくプロジェクトに参画するメンバーが増えた場合にも、割り当てる権限をゼロから検討し直す必要がなくなります。逆に個人ごとに権限を積み上げてきた運用では、契約が終了したメンバーの権限が残ったままになりやすくなります。役割という単位に置き換えておけば、参画のときも契約終了のときも、確認する対象は「その役割に誰が就いているか」の1点に絞られます。表の3行はいずれも、手引きが示す確認ポイントを役割という単位で書き直したものであり、権限の種類ごとに新しい基準を作ったものではありません。
役割への対応づけができていれば、次に確認するのは「誰が」ではなく「その役割にふさわしい担当者が就いているか」です。次の章では、管理担当者そのものに求められる条件を見ていきます。
3. 担当者は「特性を理解した」人に限られます
担当者を置くだけでは、確認ポイントを満たしません
運用の確認ポイントには、管理担当者を決めることも含まれます。手引きはここで、クラウドサービスの特性を理解した管理担当者を社内に確保しているかを確認するよう示しています6。担当を割り当てるだけでなく、クラウドサービス特有の設定や権限の仕組みを理解していることが条件になっています。役割の一覧に名前を入れる作業と、その役割に見合う理解を備えているかの確認は、別の作業として扱う必要があります。
この条件は、担当者の人数を増やすことでは満たせません。同じ担当を置いていても、クラウドサービスの特性への理解の深さによって、権限設計の精度は変わります。クラウドの権限管理に関わる案件は、Remoguで案件の90%以上がフルリモート可能です11。ただし条件は案件によって異なります。担当者の理解の深さは、資格の有無だけで測れるものではなく、権限を役割へ対応させる作業を実際にどこまで説明できるかにも表れます。
クラウドの権限管理に関わる案件を担当する場合、単に設定変更の作業を代行するだけでなく、なぜその権限構成にするのかを説明できることが期待される場面があります。特性を理解しているかどうかは、こうした説明の場面で違いとして表れます。設定の手順を知っていることと、その設定が何を守っているのかを理解していることは、別の力量です。
図の作成:Remogu編集部。手引きが示す確認ポイントの考え方を整理したもので、統計データではありません
クラウド運用に関わるリモート案件をチェックする →
担当者の条件を確認したところで、次は認証の仕組みに目を移します。共有アカウントという、別の落とし穴が残っているためです。
4. 共有アカウントは前提にできません
認証で確認される3つの項目
認証を厳格に行う場面でも、利用者の範囲を決める考え方は続きます。手引きは、攻撃に対して破られにくいパスワードを用いること、ID・パスワードを共有しないこと、電子証明書や2段階認証といった他の認証機能も利用することを挙げています7。1つのIDを複数人で使い回す運用は、この確認項目と相容れません。権限を役割に対応させていても、IDそのものが共有されていれば、誰がその役割として操作したのかが分からなくなります。
共有アカウントは、運用を簡略化する手段ではありません。むしろ確認ポイントが崩れる入り口です。1つのIDを共有する運用よりも、担当ごとにIDを分ける運用のほうが、誰がいつ何をしたかを追いやすくなります。
共有アカウントを避ける運用は、手間が増えるように見えて、実際には確認の手間を減らす方向に働きます。誰の操作かが記録に残っていれば、権限の見直しや事故が起きたときの調査を進める際に、対象を早く絞り込めるためです。反対に共有アカウントのままでは、操作した人物を特定する作業から始めることになり、確認の初動が遅れます。役割に権限を対応させる考え方も、アカウントが個人単位で分かれていることが前提になっており、共有アカウントとは相性がよくありません。
| 確認項目 | 内容 |
|---|---|
| パスワードの強度 | 攻撃に対して破られにくいパスワードを用いること7 |
| IDの共有 | ID・パスワードを共有しないこと7 |
| 追加の認証手段 | 電子証明書や2段階認証といった機能も利用すること7 |
認証の仕組みを整えていても、それだけで事故を防げるわけではありません。次の章では、利用者側の設定とは別の要因で起きる事故を確認します。
5. 事故は利用者側の不注意だけでは起きません
原因の異なる2つの事故例
権限や認証を整えていても、事故は事業者側の要因で起きることがあります。手引きが挙げる例では、レンタルサーバー・クラウドサービス事業者において5,000件を超える顧客データが消失し、原因は事業者側のシステムメンテナンスの作業ミスでした8。別の例では、ファイル転送サービス事業者において480万件を超える利用者の個人情報とログイン情報が漏えいし、原因はサーバーの脆弱性に対するサイバー攻撃でした9。どちらの例も、利用者側の権限設定や認証の運用とは別の場所で発生しています。
2つの事故は、規模も原因も異なります。利用者側の設定を疑うことよりも、事業者側の体制まで確認することのほうが、原因の全体像に近づきます。権限の設計と認証の仕組みは利用者側の対策であり、事業者側の対応を確認する作業とは別に進める必要があります。原因が事業者側にあるか利用者側にあるかを分けて考える習慣は、事故が起きたときだけでなく、サービスを選ぶ段階での確認にも役立ちます。
出典:独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」(2026年6月)をもとに作成
事故の原因が事業者側にある場合、利用者側でできる備えは限られます。それでも、権限を役割に対応させ、共有アカウントを避けておけば、事故が起きた際にどの権限がどこまで影響したのかを追いやすくなります。備えの意味は、事故を完全に防ぐことではなく、起きたときの確認を早く進められる状態を保つことにもあります。
事故の原因を分けて見ると、選ぶ段階に立ち戻る必要が見えてきます。事業者側の体制まで含めて、サービスを見極める視点が欠かせません。
6. 選ぶ基準は業務の側にあります
機能の比較より先に、業務の要件を言語化します
サービスを選ぶ基準は、機能の豊富さではなく業務の側にあります。手引きは、クラウド化する業務によって重視すべきセキュリティ対策が異なるため、業務のセキュリティ要件に見合ったサービスを選定するよう示しています3。選定の後も、事業者と利用者がセキュリティの役割・責任を分担して対策を維持・向上させる関係が続きます2。選定の時点で終わる作業ではなく、運用が続く限り両者の分担も続いていきます。
サービスの機能を比較することよりも、業務のセキュリティ要件を先に言語化することのほうが、選定の起点として手引きの考え方に沿います。権限をどう渡すか、担当者に何を求めるか、認証をどこまで厳格にするかは、いずれもこの業務要件から逆算して決まる論点です。
業務のセキュリティ要件を言語化する作業は、クラウドの権限管理に関わる案件を担当するときの起点にもなります。どの業務でどこまでの権限が必要かを整理しておけば、選定の理由も、運用開始後の権限設計も、同じ基準の上で説明できるようになります。基準がないまま設定だけを整えると、あとから見直しを求められたときに、判断の根拠を示しにくくなります。
選定の起点を業務に置くと、確認の流れは3段階になります
ここまでの内容を選定の流れとして並べると、業務の整理、サービスの選定、運用後の分担という3段階になります。前の段階を飛ばして次に進むと、業務要件と合わないサービスを選んでしまったり、選んだ後の役割分担があいまいなまま運用が始まったりします。3段階を順に確認することが、権限管理を後戻りさせない進め方です。
| 段階 | 確認すること |
|---|---|
| 業務の整理 | クラウド化する業務ごとに重視すべき対策を洗い出します3 |
| サービスの選定 | 業務のセキュリティ要件に見合ったサービスを選びます3 |
| 運用後の分担 | 事業者と利用者が役割・責任を分担して対策を維持します2 |
図の作成:Remogu編集部。手引きが示す考え方の流れを整理したもので、統計データではありません
クラウドの権限設計に関わるリモート案件を見る →
ここまでの確認ポイントを振り返ると、渡す範囲を先に決めること、権限を役割に対応させること、担当者と認証を整えること、事業者側の体制まで見ることの4点が、業務要件という1本の基準でつながっていることが分かります。
7. よくある質問
クラウドの権限管理に関わる案件は、リモートで参画できますか
Remoguでは、案件の90%以上がフルリモート可能です11。クラウドの権限設計や運用に関わる案件も、この傾向に沿って探すことができます。ただし条件は案件によって異なります。
権限管理を見直すには、何から確認すればよいですか
中小企業向けの手引きが示す確認事項を、選ぶ場面と運用する場面に分けて読むことから始められます1。特に運用の確認ポイントに含まれる、誰にどのような権限を与えるかという論点は、実務に直結する内容です5。あわせて、管理担当者の条件も確認しておくと考えやすくなります6。この記事で扱った権限、担当者、認証という3つの論点を、現状の運用と照らし合わせるところから着手すると、確認の抜けを見つけやすくなります。
中小企業向けの手引きですが、それ以外の企業でも参考にできますか
手引きは中小企業を対象にしたものです1。企業の規模が異なる場合でも、この記事で触れた役割への権限の対応づけや、管理担当者に求める条件といった考え方は、自社の状況に当てはめて確認する際の参考にできます。規模の異なる組織にそのまま当てはめられる基準として書かれているわけではない点は、確認しておく必要があります。
この手引き以外に、あわせて確認できる資料はありますか
手引きは参考として、中小企業の情報セキュリティ対策ガイドラインを挙げています。同ガイドラインは2026年3月27日に公表され、経営者が認識すべき3原則と、経営者が取り組むべき重要7項目の内容が記載されています10。権限管理を全社的な体制の一部として位置づける際に、あわせて確認できる資料です。
選ぶときの確認と運用するときの確認は、どちらを優先すればよいですか
手引きは、どちらか一方を優先させる書き方をしていません1。選ぶときの確認を済ませても、運用が始まってから権限や認証の状態は変化していきます。クラウドサービス安全利用チェックシートが選ぶときと運用するときの両方に確認ポイントを設けているとおり4、両方の確認を別の作業として続けることが前提になっています。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
任される範囲は案件ごとに違います。まずは条件を見比べるところから確かめられます。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*2 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*3 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*4 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*5 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*6 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*7 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*8 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*9 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*10 独立行政法人 情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」2026年6月(2026年6月)
*11 Remoguサイト公開情報(案件の90%以上がフルリモート可能)