# 政府の統一基準が求める ID の管理と委託先の対策

統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。

更新日: 2026-10-14

「政府機関等のサイバーセキュリティ対策のための統一基準」(以下、統一基準)は、国の機関などが守る共通ルールです。ID とパスワードについては、ID を適切に付けて管理し、要らなくなったら速やかに使えなくし、権限を必要最小限にすることを求めています。対策の例を示すガイドラインは、使う人ごとに ID を付けるのを原則とします。複数の人で 1 つの ID を使う「共用識別コード」は、いわゆる[共有アカウント](/guides/shared-accounts/what-is-shared-account)です。ガイドラインはこれを、やむを得ない場合に、使った人を特定できる仕組みを条件に認めています。業務を受ける民間の会社には、機関の情報を扱う業務であれば、情報を守るための対策が契約の条件として求められます。

## 統一基準群はどんな文書で、誰に当てはまるか

統一基準群は 3 つの文書からなります。サイバーセキュリティ戦略本部が「統一規範」と「統一基準」を決めます。内閣官房国家サイバー統括室は「政府機関等の対策基準策定のためのガイドライン」(以下、ガイドライン)を定めます。現行は令和 7 年度版で、統一基準は令和 8 年 9 月、ガイドラインは令和 8 年 10 月に一部改定されています。

文書ごとに求める強さが違います。統一基準は、各機関が必ず守る「遵守事項」を定めます。ガイドラインは、遵守事項を満たすための「基本対策事項」と解説を載せています。統一基準は、基本対策事項に例示された対策か、それと同等以上の対策を行うことで遵守事項を満たすよう求めています。基本対策事項のうち「以下を例とする」と書かれたものは例で、「全て含む」と書かれたものはすべて行う事項です。

適用対象は「機関等」、つまり国の行政機関、独立行政法人、指定法人です。民間の会社に直接当てはまる文書ではありません。ただし統一基準は 4.1.1 の目的・趣旨で、委託先への要求事項を調達仕様書などに定め、契約の条件にする必要があるとしています。

国の行政機関や独立行政法人などの業務を受ける会社に届くのは、この仕様書と契約に書かれた事項です。統一基準でいう業務委託は、機関の情報を扱わせる場合に限られます。ガイドライン自身も、統一基準群そのものを民間の委託先に守らせるのは、必ずしも適切でない場合があるとしています。

## ログインと ID について何を求めるか

中心は統一基準の 7.1.1「主体認証機能」です。主体認証とは、ログインする人が本人かを確かめることです。統一基準は ID を「識別コード」、パスワードなどを「主体認証情報」と呼びます。遵守事項は、アクセスする全ての人に ID とパスワードを「適切に付与し、管理するための措置」を求めます。システムを使う必要がなくなった人については、その ID が不正に使われないよう「速やかに」措置をとることを求めています。

ガイドラインの基本対策事項は、これを具体的にしています。例には、ある人に付けた ID を別の人に付けないことがあり、共用識別コードはこの例から除かれています。要らなくなった人については、ID を無効にすることや、無効にした ID を別の人に発行しないことが例に挙がります。解説は、人事異動のあとに不要な ID が残る可能性を指摘し、定期的に確かめて無効にするよう書いています。

ログインの方法について、ガイドラインはパスワード・IC カード・指紋などのうち 2 つ以上を組み合わせる方式の導入を検討するよう求めています。外から直接入れるクラウドサービスの管理者のように強い権限を持つ人には、原則としてこの強い方式を使うとしています。職員の側の決まりもあります。8.1.1 は職員に、自分の ID 以外でシステムを使わないことと、自分のパスワードの管理の徹底を求めています。

権限は 7.1.3 が扱います。必要最小限に設定し、要らない権限が付いていないかを定期的に確かめることが遵守事項です。

## 共用の ID はどこまで認められるか

ガイドラインは共用識別コードを「複数の主体が共用するために付与された識別コード」と定義しています。「情報システム上の制約や利用状況等に応じて」組織で共用する場合もある、という説明です。基本対策事項 7.1.1(2)-6 は、使う人ごとに ID を付けるのを原則とします。責任者の判断でやむを得ず共用するときは、使った人を特定できる仕組みを設け、扱いの手順を決めて、その手順に従うよう求めています。

解説はその理由を書いています。共用の ID は利用の記録だけでは誰が使ったか分からないため、不正な利用に気づきにくく、事故の原因を調べる妨げにもなり得ます。特定の仕組みの例は 3 つです。1 つ目と 2 つ目は、別のログイン方法や、入退室の管理のような物理的な確認を併せて使うことです。3 つ目は、第三者の承認を得てから使い、使ったことが通知される仕組みも設けることです。あわせて、パスワードを知る人を限ることも求めています。

## 委託先には何を求めるか

統一基準の 4.1.1「業務委託」は、委託先の選定と契約、期間中の履行状況の確認、終了時の検収を遵守事項にしています。検収は、業務の結果を確かめて受け取ることです。委託先には、期間中は対策の履行状況を定期的に報告させます。終了時は、期間を通じて対策を適切に行ったことの報告を含む検収を受けさせます。

ID に関わるのは、ガイドラインの 2 つの基本対策事項です。1 つは 4.1.1(2)-5 です。委託先に確認書などを出させ、その中に「当該委託業務に携わる者の特定」を含めます。変更があれば速やかに出し直させます。もう 1 つは 4.1.1(3)-1 です。8 つの対策をすべてあらかじめ契約に入れ、委託期間を通じて、扱う情報の格付(機密性などに応じた重要さの区分)などに応じて行わせます。8 つのうち ID に関わるのは「情報へアクセスする主体の識別とアクセスの制御」と「ログの取得・監視」です。解説によれば、8 項目は米国の NIST SP800-171(米国政府の情報を政府の外で守るための要求集)を参考にしています。

解説は、扱う情報の格付などに応じて委託先に求めることが考えられる対策を挙げます。その 1 つは、システムの利用者と使う機器を 1 人・1 台ずつ見分けられるようにすることです。管理者用のアカウントに 2 つ以上の方法でのログインを使い、一般のアカウントにも可能な限り使うことも例に入っています。記録については、守るべき情報に触れる全ての利用者の操作の記録を取ることを求めています。記録を監査で示せる形にする条件は、[監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence)にまとめています。

## 受託する会社が先に確かめておくこと

受託する会社が ID の決まりに出会う経路は 2 つあります。1 つは、機関のシステムに入る ID をもらう場合です。7.1.1 は「情報システムにアクセスする全ての主体」が対象なので、機関の決まりがそのまま当てはまります。もう 1 つは自社のシステムで機関の情報を扱う場合で、4.1.1(3)-1 として契約に入った事項が当てはまります。どの対策が契約に入るかは案件ごとの仕様書で決まるので、該当箇所を読み、下の表の行に当てはめて確かめます。

| 求めること | 書かれている場所 | 強さ |
| --- | --- | --- |
| 要らなくなった人の ID を速やかに止める | 統一基準 7.1.1(2)(b) | 遵守事項 |
| 権限を必要最小限にし、定期的に確かめる | 統一基準 7.1.3(1) | 遵守事項 |
| 使う人ごとに ID を付ける | ガイドライン 7.1.1(2)-6 | 基本対策事項 |
| 共用の ID は、使った人を特定する仕組みと手順を条件に | ガイドライン 7.1.1(2)-6 | 基本対策事項 |
| 強い権限は原則 2 つ以上の方法でログイン | ガイドライン 7.1.1(1)-2 | 基本対策事項 |
| 委託業務に携わる人を確認書で特定 | ガイドライン 4.1.1(2)-5 | 基本対策事項(全て含む) |
| 利用者の識別と記録を契約に入れる | ガイドライン 4.1.1(3)-1 | 基本対策事項(全て含む) |

共用の ID を使う業務では、名簿の人だけが使い、外れた人の利用を止めたことを示せると説明しやすくなります。示す場面は、確認書の出し直しと定期報告、終了時の報告です。


## よくある質問

**民間の会社も統一基準を守る必要がありますか**

直接の対象は国の行政機関・独立行政法人・指定法人です。その業務で機関の情報を扱う会社には、渡された情報を守るための対策が、調達仕様書と契約に書かれた範囲で求められます。

**統一基準は共用の ID を禁じていますか**

禁じてはいません。原則は 1 人に 1 つの ID です。ガイドラインは、責任者の判断でやむを得ず共用する場合に限り、使った人を特定できる仕組みと扱いの手順を設けることを条件にしています。

**2 段階のログインは必須ですか**

ガイドラインは、2 つ以上の方法を組み合わせる方式の導入を検討するよう求め、強い権限を持つ人には原則として使うとしています。委託先では管理者用のアカウントでの採用を例に挙げています。

**委託先の担当者の名簿は求められますか**

ガイドラインは、委託業務に携わる者の特定を含む確認書を委託先に出させ、変更があれば速やかに出し直させるよう求めています。

## 参考資料

- [内閣官房国家サイバー統括室「政府機関等のサイバーセキュリティ対策のための統一基準群」(ページ)](https://www.cyber.go.jp/policy/group/general/kijun.html)
- [サイバーセキュリティ戦略本部「政府機関等のサイバーセキュリティ対策のための統一基準(令和 7 年度版)」(令和 8 年 9 月 14 日一部改定)](https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf)
- [内閣官房国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」表紙〜第 2 部](https://www.cyber.go.jp/pdf/policy/general/guider8_6_01.pdf)
- [内閣官房国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」第 3 部〜付録](https://www.cyber.go.jp/pdf/policy/general/guider8_6_02.pdf)
- [内閣官房国家サイバー統括室「政府機関等のサイバーセキュリティ対策のための統一基準群の概要」](https://www.cyber.go.jp/pdf/policy/general/kijyungun-gaiyor7.pdf)

## Junify の場合

**人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。

**Junify なら** 確認書の担当者を差し替えるたび、自社で共用している ID はパスワードを変えて残る人に知らせ直し、定期報告の前には使用簿と名簿を照らし合わせます。Junify に載せた ID なら、差し替えは割り当ての付け外しで済みます。パスワードは導入時に変えて Junify だけが持つため、外した人はその時点で入れません。担当者はスマホで本人確認をして入り、誰がいつ使ったかの記録を名簿と並べて報告に使えます。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。
- [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。
- [内部監査でアカウントの管理を確かめるときの観点と記録](/guides/compliance/internal-audit-account-checklist): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。