# 総務省テレワークセキュリティガイドライン第 5 版と私物端末

第 5 版は対策を経営者・管理者・勤務者に分けます。管理者には多要素認証、不要なアカウントの削除、ログイン後の記録の取得を、勤務者には認証情報を無断で貸さないことを求め、私物端末はテレワークの方式ごとに可否を決めます。

更新日: 2026-09-18

総務省の「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)は、対策を 3 つの立場に分けて書いています。経営者、システム・セキュリティ管理者、テレワーク勤務者です。アカウントと本人確認に関わる対策は「アカウント・認証管理」の分類にまとまっています。管理者には、多要素認証(パスワードに加えてもう 1 つの方法で本人を確かめること)の強制を求めます。異動や担当変更に合わせた不要なアカウントの削除と、ログイン後の記録の取得も管理者の対策です。勤務者には認証情報を無断で貸さないことを求めます。私物端末(個人所有端末、BYOD)は、テレワークの方式ごとに考慮事項が書かれ、可否は組織が決めます。

## 第 5 版の構成と読み方

対策は 13 の分類(A〜M)に分かれ、それぞれに「基本対策」と「発展対策」があります。アカウントに関わる分類は 4 つです。D 特権管理(管理者権限の保護)、H アカウント・認証管理、I アクセス制御・認可(必要最小限の人に限ること)、J インシデント対応・ログ管理です。個人事業主は 3 つの立場をすべて兼ねます。

## 管理者に求められる対策

アカウントと本人確認に関わる管理者の対策を抜き出し、番号と平易な言い換えで並べます。すべて基本対策です。

| 番号 | 対策 | 平たく言うと |
| --- | --- | --- |
| H-1 | 利用者認証機能について、多要素認証方式の利用やパスワードポリシーの規定など技術的な基準を明確に定める | 本人確認の方法とパスワードの決まりを文書にする |
| H-2 | 社内システムやクラウドサービスへのアクセス時に、可能な限り多要素認証を強制する | パスワードだけで入れないようにする |
| H-4 | 強力なパスワードポリシーの適用を強制する | 短い・単純なパスワードを設定できないようにする |
| H-5 | 初期パスワードが強制的に変更されるか、十分な強度の個別のパスワードが設定されるようにする | 配ったときのパスワードのまま使わせない |
| H-7 | 異動や担当変更等を適切に把握し、不要なアカウントの削除やアカウント権限の更新等を実施する | 担当が変わったら要らない ID を消す |
| D-1 | 貸与する端末には必要最小限の権限(例: ユーザ権限)を付与する | 端末の管理者権限を普段は使わせない |
| D-3 | 製品やクラウドサービスの管理者権限は業務上必要な最小限の人にのみ適用し、アクセス経路も限定する | 管理者権限を持つ人と入る経路を限る |
| J-5 | テレワーク関連機器やクラウドサービスの記録(ログインした後の認証ログ、操作ログなど)を取得する | 誰がいつ入り何をしたかの記録を取る |
| J-6 | 取得したログの保存容量を確保し、可能な限り 1 年以上保存可能とする | 記録を 1 年以上残す |
| B-1 | テレワーク端末を管理する台帳を整備し、利用者や所在を把握する | どの端末を誰が使っているかの一覧を持つ |

解説の章は、異動や担当者変更に際して「権限がなくなるべき者に権限が残ったままにならないよう運用する必要があります」と書いています。パスワードの定期的な変更は原則不要としています。例外は、第三者に知られたおそれがあるときや、共有アカウントなどで利用メンバーに変更があったときなどで、速やかに変更するよう求めています。共有アカウントに触れているのはこの 1 か所です。

## 勤務者に求められる対策

| 番号 | 対策 | 平たく言うと |
| --- | --- | --- |
| H-1 | 利用者認証情報(パスワード、IC カード等)を無断貸与や紛失等しないよう、適正に管理する | 自分の ID とパスワードを人に貸さない |
| H-2 | 第三者に推測されにくいパスワードを設定する。長く設定できる場合は複数の単語を組み合わせる | 長いパスワードにする |
| H-3 | 複数のサービス間で同じパスワードを使い回さない。知られた可能性があれば早急に変更する | 使い回さず、漏れたら変える |
| I-3 | 共有フォルダやファイル共有サービスに機密情報を保存する場合、閲覧・編集の権限が誰にあるか確認する | 共有場所の権限を確かめる |
| B-1 | テレワーク端末が守るべき情報資産に当たることを認識して管理する | 端末は会社の資産として扱う |

勤務者 H-1 の「無断貸与」は、会社の許可なく自分の認証情報を他の人に使わせることです。会社が決めて共有するアカウントは、管理者側の H-7 と、上の共有アカウントのパスワード変更の記述で扱われています。

## 私物端末はどう扱われるか

ガイドラインは 7 つのテレワーク方式を解説し、方式ごとに「BYOD 利用について」の項を置いています。端末は支給端末と個人所有端末の両方を想定しますが、VPN 方式・クラウドサービス方式・スタンドアロン方式は、メリットが大きい支給端末を想定した評価です。自社が使っている方式の項を読みます。

### VPN・クラウドサービス・スタンドアロンの 3 方式

VPN(社内ネットワークにつなぐ)、クラウドサービス(インターネット上のサービスに直接つなぐ)、スタンドアロン(社内につながず端末内のデータで作業する)の 3 つでは、端末にデータを保存でき、対策ソフトの導入を強制できないため、十分な管理が取れないとしています。事故が起きうるリスクを受け入れられるかを評価したうえで、利用の可否を決めることになります。

### リモートデスクトップ・仮想デスクトップの 2 方式

リモートデスクトップ(社内のパソコンを遠隔操作する)と仮想デスクトップ(サーバー上の画面を遠隔操作する)では、端末へのデータ保存を制限・禁止します。そのうえで、利用のルールを決め、端末に必要な対策があることを確認し、端末を管理します。

### セキュアコンテナ・セキュアブラウザの 2 方式

セキュアコンテナ(端末内に業務専用の区画を作る)とセキュアブラウザ(専用のブラウザーで社内のシステムを使う)でも、利用のルールを決め、端末の対策を確認し、端末を管理します。セキュアブラウザについては、製品の仕様を確かめるよう書いています。

事例の章は、「個人所有端末の業務利用に当たってはセキュリティ対策をテレワーク勤務者任せにせず、組織として適切なセキュリティ対策を実施する必要があります」と書いています。

## 立場別に見た私物端末とアカウント

私物端末では、会社が端末の中を管理できないため、アカウントの側で守る部分が増えます。ガイドラインの対策を立場別に当てはめると、次のようになります。

経営者は、私物端末を認めるかどうかを、方式ごとのリスクを見て決めます。認めるなら方針を周知します。関わるのは A-1 と、方式ごとの「BYOD 利用について」の項です。

管理者は、私物端末から入るサービスに多要素認証を強制し(H-2)、私物端末の一覧を持ちます(B-1)。担当変更のときには不要なアカウントを消し(H-7)、ログイン後の記録を 1 年以上残します(J-5、J-6)。

勤務者は、認証情報を家族や同僚に貸さず、パスワードを使い回さないようにします(H-1〜H-3)。端末は会社の資産として扱います(B-1)。

誰が使ったかの記録と、担当変更時に不要なアカウントを消すことは、他の法令や指針でも同じ形で求められます。共通の点は[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。私物端末のブラウザーにパスワードを保存する扱いは、ガイドラインにコラムがあります。会社としての判断は[ブラウザーのパスワード保存を業務で使ってよいか](/guides/shared-accounts/browser-saved-passwords-at-work)に整理しています。


## よくある質問

**私物端末でのテレワークは認められていますか**

ガイドラインは禁じていません。方式ごとに、データ保存やソフト導入の強制ができない点を挙げ、リスクを受け入れられるか評価して可否を決めるよう求めています。

**多要素認証は必ず必要ですか**

管理者の基本対策 H-2 は「可能な限り多要素認証を強制する」です。認証情報が漏れてもただちに入られないための対策として、社内システムにも同様に求めています。

**パスワードは定期的に変えるべきですか**

原則不要としています。例外は、第三者に知られたおそれがあるときや、共有アカウントで利用メンバーに変更があったときなどで、速やかに変更します。

**記録はどのくらい残しますか**

J-6 は、過去にさかのぼった調査も必要になるため、可能な限り 1 年以上保存できるようにするとしています。対象は認証ログや操作ログなどです。

## 参考資料

- [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf)

## Junify の場合

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

**Junify なら** Junify は、私物端末で問われる、誰が使ったかの記録と、担当変更時に止めることを担います。担当者はスマホで本人確認をしてからブラウザーの拡張機能で使うので、記録は一人ひとり残ります。パスワードは端末に渡らず、担当を外れたら割り当てを外します。

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

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

## 同じテーマの記事

- [個人情報保護法の安全管理措置をアカウント管理に当てはめる](/guides/compliance/appi-safety-measures-for-accounts): 通則編の別添が求める「アクセス制御」と「アクセス者の識別と認証」、24 条の従業者の監督、25 条の委託先の監督を、共有アカウント・退職者・委託先の 3 場面に当てはめ、用意する一覧と記録を表にします。
- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版のアカウント管理項目](/guides/compliance/ipa-sme-guideline-accounts): 第 4.0 版は、ID の発行から削除までの手続、共有 ID を使った人の特定、パスワードの保管ルール、異動・退職時の権限の変更・削除、契約終了時のアクセス権の回収を挙げます。本編・付録 3・付録 5 の当てはまる箇所を点検表にします。
- [ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](/guides/compliance/iso27001-access-control-for-saas): 取り上げる管理策は、5.15 アクセス制御、5.16 識別情報の管理、5.17 認証情報、5.18 アクセス権、8.2 特権的アクセス権の 5 つです。SaaS では、使える人の一覧、ID の作成と削除、パスワード、管理者権限に当たります。