LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

開発に加わってもらう業務委託のエンジニアに、どこまでの権限を渡してよいのか決めきれない。契約が終わった人のアカウントが、気づけば残ったままになっている——。社外の技術者を受け入れる開発の現場では、こうした悩みが起こりがちです。業務委託エンジニアの受け入れにおける権限管理とは、社外から加わる技術者に渡すアカウントとアクセスの権限を、渡すとき、使っている間、契約が終わるときの3つの場面を通して管理することを指します。

渡し方と消し方を先に決めておけば、参画のたびに担当者が迷わずに済みます。ただし万能ではなく、決めた手順どおりに一覧を更新し続けなければ、記録は実態とずれていきます。本記事では、開発の現場を預かるマネージャーに向けて、社員の権限管理との違い、アカウントを渡すときの決まり、管理者の権限の扱い、定期的な見直し、契約終了と交代のときの削除、つまずきやすい点、そして外部に委託するときに確認しておきたい点を整理します。

業務委託エンジニアの権限管理とは

管理するものは、大きく3つに分けられます。1つ目は、本人を見分けるためのアカウント（ID）です。ソースコードの保管場所、課題管理のツール、クラウドの管理画面など、使ってもらうシステムの数だけ発行します。2つ目は、そのアカウントに付ける権限です。読むだけか、書き込めるか、設定まで変えられるかといった違いがあります。3つ目は、サーバーやデータベースの設定を変えられる管理者の権限で、これはほかの2つと分けて扱います。

手順を決めるときの手がかりになるのが、経済産業省の「情報セキュリティ管理基準（令和7年改正版）」です。情報セキュリティの国際規格に沿って、組織が選んで使う管理策（情報を守るための対策）を並べた基準で、アクセス権については、組織の方針と規則に従って「提供、レビュー、変更及び削除する」としています。^*1 渡すときだけでなく、使っている間に見直し、要らなくなったら消すところまでを一続きの管理として扱う考え方です。

もう一つの手がかりが、国の機関向けの「政府機関等のサイバーセキュリティ対策のための統一基準（令和7年度版）」です。2025年6月27日にサイバーセキュリティ戦略本部が決定したものです。民間企業に守る義務はありませんが、あわせて公表されているガイドラインには措置の例が具体的に並んでいます。

社員の権限管理との違い

1つ目の違いは、終わりの日が先に決まっていることです。業務委託の契約には期間があるので、アカウントを作る時点で、いつ使えなくなるべきかが分かっています。社員のように退職の届出を待たなくても、契約の終了日をそのまま削除の予定日にできます。

2つ目は、本人の状況が変わっても社内の人事の記録には載らないことです。委託先の会社の中でエンジニアが別の案件へ移っても、自社の人事部門には連絡が来ません。管理基準は、アカウントを無効化または削除する場面の例として、ひも付けられた人が「組織を去った若しくは役割を変えた場合」を挙げています。^*1 業務委託エンジニアでは、それを知らせてくれるのは委託先の会社か本人なので、連絡の取り決めが要ります。

3つ目は、同じ役割のまま人が入れ替わることです。委託先の都合で担当者が交代すると、前の人のアカウントを後任にそのまま使ってもらいたくなります。後で触れるとおり、これは避けたいやり方です。

アカウントを渡すときの決まり

最初の決まりは、アカウントを1人に1つにすることです。管理基準は、あるアカウントで行われた処理についてその人に説明の責任を負わせられるよう、「一つの識別情報は一人の個人にだけひも（紐）付ける」としています。複数の人で使うアカウントは、業務上または運用上の理由で必要で、承認と文書化をする場合にだけ許すとしています。^*1 チームで1つのアカウントを回して使っているなら、それがこの例外に当たるかを一度確かめておきたいところです。

次に、付ける権限を担当する作業に要る範囲にとどめます。統一基準は、主体（システムを使う人）から対象へのアクセスの権限を「必要最小限の範囲で適切に設定する」よう求めています。^*2 全てにアクセスできないことを前提に、必要がある人にだけ権限を付けるのが原則です。画面の改修を頼んだなら、開くのはその画面に関わるシステムと検証用の環境までにして、本番のデータベースには権限を付けない、という渡し方になります。

アカウントの発行と承認は、社内の人が行います。管理基準は、アクセス制御の方針で考慮する事項として、アクセスの要求、認可、管理といった機能の分離や職務の分離を挙げています。頼む人、認める人、設定する人を分けておけば、誰かが自分の判断だけで権限を増やすことはできません。

管理者の権限の扱い

管理者の権限は、できる操作の幅が広いぶん、渡し方にも別の決まりがあります。統一基準は、限られた人だけに管理者の権限を付けることが重要だとしています。^*2 ガイドラインは、管理者の権限を付けるときの措置の例として次の4つを挙げています。

開発を頼んでいる業務委託エンジニアに、本番のサーバーの管理者の権限を常に付けておく必要があるかどうかは、この4つに照らすと判断しやすくなります。障害の調査や定期の保守で管理者の操作が要るときだけ使えるようにする、という形が一つの答えです。管理基準も、特権的アクセス権（管理者の権限）を永続的に許すのではなく、承認された変更や活動を行うのに「必要な時間枠だけ一時的な特権的アクセスを許可する」としています。^*1

付ける場合でも、ふだんの作業には使わせません。ガイドラインは、管理者の権限を持つアカウントの利用は権限が要る業務に限り、一般の業務には使わせないとしています。通常の作業用と管理用のアカウントを分けて渡し、管理用は保守のときだけ使ってもらえば、いつ管理者の操作をしたのかが記録から追いやすくなります。

定期的な見直しの進め方

権限は、渡した日のままにはとどまりません。作業が進むにつれて別のシステムの権限を追加し、障害の対応で一時的に管理者の権限を付け、それが外されずに残る。こうして少しずつ増えていきます。統一基準は、不要なアクセスの権限が付けられていないかを「定期的に確認すること」を求めています。^*2

管理基準は、アクセス権を定期的にレビューするときに考慮する事項として、組織の中での異動や昇進などの変更の後、または退職の後の利用者のアクセス権と、特権的アクセス権の認可の2つを挙げています。^*1 業務委託エンジニアなら、担当する作業の変更や委託先の会社の中での交代がこれに当たります。見直しでは、次の3つの記録を照らし合わせます。

長く使われていないアカウントも手がかりになります。ガイドラインは、最初に渡したパスワードが変更されないまま、つまり使われていないアカウントを無効にするなどの措置を挙げています。ガイドラインはまた、退職などで要らなくなったアカウントの無効化について、本人からの届出を待つだけでなく「定期的に不要な識別コードが存在しないことを確認することが望ましい」としています。^*3

見直しの結果は、誰がいつ何を外したかまで残しておくと、次の回は前回との違いを見るだけで済みます。

契約終了と交代のときの削除

契約が終わった人のアカウントは、終了日に合わせて使えなくします。統一基準は、主体がシステムを利用する必要がなくなったときは、そのアカウントとパスワードなどの不正な利用を防ぐ措置を「速やかに講ずること」としています。^*2

ガイドラインは、その措置の例として3つを挙げています。アカウントを無効にすること、渡していたICカードなどの認証用の装置を返してもらうこと、無効にしたアカウントを別の人に新しく発行しないことです。^*3 3つ目は交代の場面で効いてきます。前任のアカウントの名前だけ変えて後任に渡すと、過去の操作が誰のものか分からなくなります。交代では、後任のアカウントを新しく作ることと前任のアカウントを止めることを、同じ日に行うと抜けが出にくくなります。

消し漏れが起きやすいのは、社内の仕組みとは別に登録しているサービスです。クラウドの管理画面や社外のチャットに招待していると、社内のアカウントを止めても、そちらには入れたままです。受け入れのときに使ってもらうシステムを一覧にしておけば、終了のときはそれを上から消していけば済みます。

つまずきやすい点

一つめは、初めから用意されている管理者のアカウントを共有してしまうことです。ガイドラインの解説は、Administrator、root、admin のように初期値として使える管理者のアカウントは不正アクセスの標的になりやすく、無効にすることが望ましいとしています。^*3 急ぎでも、このパスワードを業務委託エンジニアに伝えるのは避けます。

二つめは、権限を付ける人と使う人が同じになることです。前の表の3番目のとおり、ガイドラインは同一の者が権限の付与と執行を兼ねないようにする措置を挙げています。長く参画している業務委託エンジニアにアカウントの発行まで任せていると、自分で自分に権限を付けられる状態ができてしまいます。

三つめは、交代の知らせが遅れることです。委託先の会社の中でエンジニアが入れ替わっても、自社の担当者が知るのは後任が初めて打ち合わせに来た日、ということがあります。交代が決まった時点で知らせてもらう約束を契約や発注の書面に入れておけば、前任のアカウントを止める日を前もって決められます。

外部に委託するときに確認しておきたい点

業務委託エンジニアを受け入れる前に、任せる作業と、そのために使ってもらうシステムを書き出しておきます。受注管理の画面の改修なら、ソースコードの保管場所、検証用の環境、課題管理のツールまでは要るが、本番のデータベースは要らない、といった線を引けます。この書き出しがあれば、求める経験も渡す権限も決めやすくなります。委託先の会社には、交代や離任をいつまでに知らせてもらうかを参画の前に伝えておきます。

受け入れのときの手続き全体は業務委託エンジニアの受け入れで決める5つの手続きで扱っています。

契約終了のときに決めておく項目はSES契約終了で決める6項目にまとめました。

離任のときの情報漏えい対策は業務委託エンジニアの離任時に情報漏えいを防ぐ3つの対策で整理しています。

まとめ：権限管理で確かめておきたい3つの点

業務委託エンジニアの受け入れで権限管理を決めるうえで、確かめておきたい点は3つに整理できます。第一に、アカウントを1人に1つ発行し、権限を作業に要る範囲にとどめること。第二に、管理者の権限は作業に要る間だけ付け、契約・アカウント・管理者の権限の記録を照らし合わせて定期的に見直すこと。第三に、契約の終了や交代のときに前任のアカウントを速やかに無効にし、後任には新しいアカウントを作ることです。この3点を踏まえておけば、「契約が終わった人のアカウントが、誰も気づかないまま使える状態で残っていた」という事態を避けやすくなります。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：経済産業省「情報セキュリティ管理基準（令和7年改正版）」（PDF）（https://www.meti.go.jp/policy/netsecurity/is-kansa/IS_Management_Standard_R7.pdf）。出典：経済産業省「情報セキュリティ管理基準（令和7年改正版）」。1.1（主旨）、5c-5.15.3（アクセス制御の方針で考慮する事項）、5c-5.16.1・5c-5.16.3（識別情報の管理）、5c-5.18（アクセス権）の管理策と5c-5.18.2（アクセス権のレビュー）、8a-8.2.2（特権的アクセス権）を参照（確認日2026年9月29日）（2026年9月確認）
2. *2　参考：サイバーセキュリティ戦略本部「政府機関等のサイバーセキュリティ対策のための統一基準（令和7年度版）」（PDF）（https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf）。出典：令和7年6月27日 サイバーセキュリティ戦略本部決定。7.1.1「主体認証機能」の遵守事項(2)、7.1.3「権限の管理」の目的・趣旨と遵守事項(1)を参照（確認日2026年9月29日）（2026年9月確認）
3. *3　参考：国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン（令和7年度版）」令和8年6月一部改定 第3部〜付録（PDF）（https://www.cyber.go.jp/pdf/policy/general/guider8_6_02.pdf）。出典：7.1.1「主体認証機能」の基本対策事項7.1.1(2)-2・(2)-4・(2)-7と解説、7.1.3「権限の管理」の基本対策事項7.1.3(1)-1・(1)-2・(1)-3と解説を参照（確認日2026年9月29日）（2026年9月確認）

Tweet