- SaaSのセキュリティは、製品を増やす前に管理画面の設定を4か所直すのが先です。多要素認証・管理者権限・外部共有・ログの4点で、必要なのは予算ではなく、触る順番と、決めて適用する時間です。
- 多要素認証は「推奨」では効きません。管理画面で「適用(必須)」に切り替えるのが要点です。ただし管理者から段階的に適用できるかは製品で分かれます(Google Workspaceは組織部門単位で可能、Microsoft 365のセキュリティの既定値群はテナント一括)。どちらでも、緊急用のアカウントの確保が先です。
- 順番を間違えると自分が締め出されます。緊急用アカウントの確保と、レガシー認証で動いている機器の洗い出しを最初に置いてください。目安は、自分の作業が半日〜1日(外部共有を一覧化できないプランでは棚卸しに数日)、全社への適用は告知を含めて1〜2週間です。
「SaaSは事業者側がセキュリティをやってくれる」——半分は正しく、半分は違います。サーバーやアプリケーションの守りは事業者の仕事ですが、誰にアクセスさせるか、どこまで外へ出せるかは、契約した自社が管理画面で決めることです。導入時の既定のまま動いている会社も少なくない、というのが編集部の見立てです。
この記事は、すでに使っているSaaSのセキュリティ設定を、追加費用をほとんどかけずに固める手順をまとめたものです。対象は、中小〜中堅企業の情シス・総務・バックオフィス担当と、専任の情シスがいない会社で「なんとなく詳しい人」になっている方です。製品の比較ではなく、設定する順番と、順番を間違えたときに何が起きるかに重心を置きます。
最終更新: 2026年9月6日／本文で参照した公的資料と各社の公式ドキュメントは同日に確認しています。設定画面の名称や既定値は変更されるため、実施前に必ず各サービスの公式ドキュメントでご確認ください。
何から手をつけるか：IPAのガイドラインをSaaSの管理画面に翻訳する
独立行政法人情報処理推進機構(IPA)は、2026年3月27日に「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開しました。同版では、従来の「情報セキュリティ5か条」に「バックアップを取ろう！」が追加され、6か条になっています。原文は次のとおりです。
情報セキュリティ6か条
１．OS やソフトウェアは常に最新の状態にしよう！
２．ウイルス対策ソフトを導入しよう！
３．パスワードを強化しよう！
４．共有設定を見直そう！
５．バックアップを取ろう！
６．脅威や攻撃の手口を知ろう！
同ガイドラインは、6か条の直後に置かれた「SECURITY ACTION 一つ星」の説明の中で、これらを「企業の規模に関わらず、必ず実行すべき重要な対策です。」と位置づけています。ここで重要なのは、1・2・5は端末とデータの話ですが、3・4はそのままSaaSの管理画面の設定になるという点です。SaaS中心の職場では、3と4の比重が相対的に大きくなります。
具体的な対策例は、同ガイドラインが収録する「５分でできる！情報セキュリティ自社診断」(解説編) Part 1 基本的対策に、6か条と並行する番号で載っています。No.3「強固なパスワードを使用する」(パスワード管理)の対策例は4つあり、そのうちSaaSに直接効くのは次の1つです。
「□ 特にVPNや重要なシステムを利用する場合は、強固なパスワードを設定し、可能な場合は多段階認証、多要素認証、パスキーなどの認証強化機能を利用する。」
No.4「共有設定を見直す」(機器の設定)の対策例も4つあり、そのうち2つがSaaSの共有設定に直接関わります。
「□ ウェブサービス、ネットワーク接続の複合機・カメラ、ハードディスク（NAS）などの共有範囲を限定する。」
「□ 従業員の異動や退職時には速やかに設定を変更（削除）する。」
この記事では、以上に本編の技術的対策を加えて、SaaSの管理画面で押す4つの設定に翻訳します。先に断っておくと、4つのうち6か条に対応するのは①認証と③共有の2つだけです。②権限と④ログは6か条ではなく、本編「取組3」の対策から取っています。次の表で対応関係を示します。
| IPA第4.0版の該当箇所 | SaaSでの主な作業場所 | 本記事での扱い |
|---|---|---|
| 6か条１．OS やソフトウェアは常に最新の状態にしよう！ | 利用する端末側(SaaS本体は事業者が更新) | 本記事の対象外(端末管理の領域) |
| 6か条２．ウイルス対策ソフトを導入しよう！ | 利用する端末側 | 本記事の対象外 |
| 6か条３．パスワードを強化しよう！ | 認証設定(多要素認証の適用、パスキー、パスワードポリシー) | 設定①で扱う |
| 6か条４．共有設定を見直そう！ | 外部共有・リンク共有・ゲスト招待の既定値 | 設定③で扱う |
| 6か条５．バックアップを取ろう！ | ゴミ箱の保持期間・版履歴・復元可能期間 | 本記事では扱わない(第4.0版で追加された項目で、10大脅威1位のランサム対策にも直結する論点だが、設定の性質が異なるため) |
| 6か条６．脅威や攻撃の手口を知ろう！ | 外部の注意喚起の購読と、社内への周知 | 本記事では扱わない(情報収集の領域) |
| 本編 取組3＞(5)＞①「システム及び情報の重要度に応じて認証の強度及び実装方法を決定する」 | 多要素認証の適用方法・認証の強度 | 設定①で扱う(6か条３と合わせて) |
| 本編 取組3＞(5)＞①「ユーザー ID 及び管理者 ID の発行・変更・削除の手続を定める」「アクセス権の管理ルールを定める」 | ユーザー管理・管理者ロール・アクセス権 | 設定②で扱う |
| 本編 取組3＞(5)＞③「情報機器及びシステムに関するログを取得し、異常を検知するため、定期的にレビューを行う」 | 監査ログ・不審なサインインの通知 | 設定④で扱う |
左列はIPA第4.0版の原文です(上6行は「情報セキュリティ6か条」の項目名、下3行は本編の対策名)。左列の「取組3＞(5)＞①」等はIPA自身が用いている節番号で、本記事の「設定①〜④」とは別の体系です。中央・右列の対応づけはjisalab編集部の整理であり、IPAの資料に同じ対応表があるわけではありません。SaaSの機能名・提供範囲は製品とプランによって異なります。
脅威の側の状況も見ておきます。IPAが2026年1月29日に公開した「情報セキュリティ10大脅威 2026」の【組織編】は、1位「ランサム攻撃による被害」、2位「サプライチェーンや委託先を狙った攻撃」、3位「AIの利用をめぐるサイバーリスク」と並び、7位「内部不正による情報漏えい等」、8位「リモートワーク等の環境や仕組みを狙った攻撃」が入っています。この順位は、約250名のメンバーからなる「10大脅威選考会」の審議・投票を経て決定されたものです。このうち2位・7位・8位は、SaaSの認証・権限・共有設定が関係する領域です。ただしこの順位は脅威のランキングであって、作業の順番を示すものではありません。以下で示す作業順は、編集部が「止まったときに戻せるか」を基準に組んだものです。
設定①：多要素認証を「推奨」から「適用」に変える
IPAのガイドライン第4.0版は、取組3(5)①の中で次の対策を挙げています。
「●システム及び情報の重要度に応じて認証の強度及び実装方法を決定する
不正アクセスを防ぐために、取り扱う情報の重要性に応じて情報にアクセスするための本人認証方法と管理ルールを定め、複数の要素を組み合わせて認証を行う多要素認証を活用しましょう。（以下略）」
引用を途中で切ったので補足します。原文はこの後、管理者権限のリモート接続や機密性の高い情報へのインターネット経由のアクセスについて「接続元制限や端末要件を規定して遵守状況を確認」すること、さらに「アカウントロック制御を実装」してログオン試行回数の制限やアカウントロックの運用を行うことまで求めています。本記事が扱う4点は、その一部です。接続元制限と端末要件は、多くのSaaSで上位プランの機能になるため、ここでは踏み込みません。
同ガイドライン第2部 実践編「4. より強固にするための方策 (2) 技術的対策例と活用」(p.48〜)の③アクセス管理は、多要素認証を次のように定義しています。
「サービス利用時に行う利用者認証を、３つの要素（①知っているもの②持っているもの③本人自身に関するもの）のうち、２つ以上の要素を用いて行う技術。（以下略。原文はこの後、ICカード認証にパスワード認証を追加する例が続きます）」
多要素認証(続き)：段階的に適用できるかは、製品によって違う
全社一斉に必須化すると、問い合わせが集中しがちです。理屈のうえでは管理者アカウント → 機密情報を扱う部署 → 全社と段階を踏みたいところです。ところが、この段階適用ができるかどうかは製品で分かれます。ここを確認せずに計画を立てると、初日に破綻します。
Google Workspaceは段階適用ができます。設定場所は、同ヘルプによると管理コンソールの「メニュー アイコン ＞ セキュリティ ＞ 認証 ＞ 2 段階認証プロセス」です。ここで「組織部門」(主に部署に使用)または「グループ」(高度な設定)を選んで一部のユーザーに限定できるとしています。適用の開始も「今すぐ強制」と「指定した日付から適用を有効にする」の2択があり、新規従業員向けには「新しいユーザーの登録期間」を1日〜6か月で設定できます(この期間中はパスワードのみでログインできます)。管理者の組織部門だけ先に「今すぐ強制」、全社は日付指定、という進め方が素直に組めます。
一方、Microsoft 365(Microsoft Entra ID)の「セキュリティの既定値群」では、管理者だけ先に適用することはできません。公式ドキュメントの比較表は、セキュリティの既定値群のカスタマイズ性を「カスタマイズなし (オンまたはオフ)」と明記しています。テナント単位のオン・オフだけで、有効化すると適用される基本的なコントロールとして、公式は次のものを挙げています。
「- すべてのユーザーに対して、多要素認証への登録を必須にする
– 管理者に多要素認証の実行を要求する
– 必要に応じてユーザーに多要素認証の実行を要求する
– レガシ認証プロトコルをブロックする
– デバイス コード フローのブロック
– Azure portal へのアクセスなどの特権が必要な作業を保護する」
1行目のとおり、対象は「すべてのユーザー」です。ユーザーやグループを指定して段階的に適用したい場合は条件付きアクセスが必要で、同ドキュメントの比較表は、条件付きアクセスに必要なライセンスを「Microsoft Entra ID P1 以上」としています(セキュリティの既定値群は「なし」)。
したがって、セキュリティの既定値群を使う限り、進め方は「管理者から段階的に」ではなく「事前告知 → 準備 → 一括で有効化」になります。段階適用ができない以上、後述する事前準備(緊急用アカウント、レガシー認証の洗い出し)の重みが、Google環境よりも増します。戻す判断も全社単位になるためです。
ただし、Microsoft環境の選択肢が既定値群だけというわけではありません。同ドキュメントは、既定値群を無効にする場合の受け皿として「Microsoft管理の条件付きアクセス ポリシー」に触れ、これを使って「従来の認証のブロック、Azure管理に MFA を要求する、管理者に MFA を要求する、すべてのユーザーに MFA を要求する」同じ保護を維持できるとしています。「管理者に MFA を要求する」が名指しで挙がっているため、管理者だけ先に締める運用がまったく不可能というわけではありません。ただし、自社のライセンスでこのポリシーが使えるかは公式で確認してください。本記事は、追加ライセンスを前提にしない範囲での進め方を示しています。
| Google Workspace(2段階認証プロセス) | Microsoft 365(セキュリティの既定値群) | |
|---|---|---|
| 適用範囲の指定 | 組織部門またはグループ単位で可能 | 不可(テナント単位のオン・オフのみ。公式表記は「カスタマイズなし (オンまたはオフ)」) |
| 開始時期 | 「今すぐ強制」または「指定した日付から適用を有効にする」 | 有効化した時点から(新規テナントは既定で有効・24時間の猶予期間) |
| 登録の猶予 | 新規ユーザー限定で、登録期間を1日〜6か月に設定可能 | 2024年7月29日以降、ユーザーがMFAに登録するための14日間の猶予期間は削除 |
| 段階適用したい場合 | 標準機能の範囲で可能 | 既定値群では不可。条件付きアクセス(Microsoft Entra ID P1 以上)、またはMicrosoft管理の条件付きアクセス ポリシー(利用可否は自社のライセンスで要確認)を検討する |
| 現実的な進め方 | 管理者の組織部門を先に強制 → 全社は日付指定 | 既定値群で行くなら、事前告知 → 準備 → 一括で有効化 |
各社の公式ドキュメント(Google Workspace 管理者ヘルプ「2 段階認証プロセスを導入する」、Microsoft Learn「Microsoft Entra ID のセキュリティの既定値を構成する」)の記述をもとにしたjisalab編集部の整理です。両社の資料に同じ比較表があるわけではありません。仕様は改定されるため、実施前に公式でご確認ください。他のSaaSでも、範囲指定ができるかは製品とプランで異なります。
なお、セキュリティの既定値群そのものは有償ではありません。同ドキュメントは対象を「セキュリティ体制を向上させたいが、どこから始めればいいのかわからない組織。」「Microsoft Entra ID ライセンスの Free レベルを使用している組織。」とし、追加の費用なしで使える基本レベルの保護と位置づけています。まず既定値群で締め、細かい制御が必要になってから条件付きアクセスへ移行するのが、費用面では素直な順路です。
補足：よく引用される「99.9%」は、MFAだけの数字ではない
多要素認証の効果として「攻撃の99.9%を防ぐ」という数字が広く引用されています。出所であるMicrosoftの公式ドキュメントの記述は、正確には次のとおりです。
「Microsoft の知見によれば、これらの一般的な ID 関連攻撃の 99.9% 以上は、多要素認証を使ってレガシ認証をブロックすることで阻止されます。」
「多要素認証を使って」と「レガシ認証をブロックすること」の合わせ技である点が、引用の過程で落ちがちです。同じドキュメントの別の箇所には、MFA単独の数字として「MFA は 99.2% を超える ID ベースの攻撃をブロックできる」という記述もあります。いずれもMicrosoft自身が公表している数字(ベンダー自己申告値)であり、第三者機関の検証値ではありません。実務上の含意は明快です。同ドキュメントはレガシ認証を「IMAP、SMTP、POP3 などの古いメール プロトコルを使用しているクライアント」等による認証要求を指す用語とし、「レガシ認証では、多要素認証がサポートされていません」としています。MFAを入れてもレガシー認証の口を開けたままなら、そこから迂回されうる——だから2つはセットです。
多要素認証(続き)：切り替える前に、締め出されない準備を5つ
多要素認証の適用でつまずきやすいのは、攻撃ではなく管理者自身のロックアウトと、レガシー認証で動いていた機器の停止です(この2点を先頭に置くのは編集部の判断です)。次の5点を先に済ませてください。
- 緊急用のアカウントを用意する。Microsoftは、全体管理者ロールが永続的に割り当てられたクラウド専用の緊急アクセス アカウントを2つ作成することを推奨しています(この推奨は、セキュリティの既定値群から条件付きアクセスへ移行する節に置かれており、専用の解説ページも用意されています)。通常のアカウントが使えない緊急時や、すべての管理者が誤ってロックアウトされる「ブレイクグラス」シナリオに限定して使うアカウントです。既定値群を有効にする日の準備としてこれを筆頭に置くのは、編集部の判断です。Google Workspaceにも同趣旨の推奨があり、管理者ヘルプ「管理者アカウントのセキュリティに関するおすすめの方法」は「組織では複数の特権管理者アカウントを用意して、それぞれを別のユーザーが管理することをおすすめします」とし、さらに「特権管理者にはそれぞれ 2 つのアカウント（専用の特権管理者アカウントと、日常業務に使用する別のアカウント）を付与してください」としています
- 復旧の手段を先に持っておく。同ヘルプは「セキュリティ キーまたはスマートフォンを紛失した場合は、バックアップ コードを使用してログインできます」としています。特権管理者のバックアップコードは、適用前に発行してオフラインで保管しておくのが安全です(この順番は編集部の判断です。同ヘルプは「必要な場合に備えて」用意しておくことを勧めています)
- レガシー認証で動いているものを洗い出す。公式ドキュメントは「セキュリティの既定値群を有効にする前に、管理者が古い認証プロトコルを使用していないことを確認してください。」と警告し、あわせて多機能機器やアプリケーションからメールを送信する設定の案内へリンクしています。この警告文が名指ししているのは管理者の利用状況ですが、実務で止まりやすいのは、スキャンした書類をメール送信している複合機、古い業務アプリからの自動送信、社内サーバーのバッチ処理です(この3点は編集部の整理です)
- 使える認証方法を、製品ごとに先に確かめる。ここは製品差が大きい箇所です。Google Workspaceはセキュリティキーやパスキーを選べますが、Microsoftのセキュリティの既定値群では選択肢が限られます。公式ドキュメントは「セキュリティの既定値群のユーザーは、通知を使用する Microsoft Authenticator アプリを使って多要素認証に登録し、多要素認証を使用する必要があります」とし、確認コードは使えるものの「通知オプションを使用した場合にのみ登録できます」、加えて「OATH TOTP を使用して Microsoft 以外のアプリケーションを使用してコードを生成することもできます」としています。つまり既定値群で公式が必須としているのはAuthenticatorアプリで、代替として案内されているのはOATH TOTPのアプリです。セキュリティキーは、この案内には出てきません。私物端末を使えない人がいる場合の現実解は、業務用端末の貸与か、条件付きアクセスへの移行の検討になります
- 認証方法を無効にしない。同ドキュメントは「セキュリティの既定値を使用している場合は、組織のメソッドを無効にしないでください。方法を無効にすると、テナントからロックアウトされる可能性があります。」と警告しています
操作の場所も書いておきます。セキュリティの既定値群は、公式ドキュメントによるとMicrosoft Entra 管理センターにサインインし、「Entra ID」＞「Overview」＞「Properties」から「セキュリティの既定値群の管理」を選び、「有効」に設定して保存します(操作には少なくとも条件付きアクセス管理者のロールが必要)。あわせて同ドキュメントは、有効化の一環として「管理者は既存のすべてのトークンを取り消して、すべてのユーザーに多要素認証の登録を要求する必要があります」とし、Microsoft Graph PowerShell SDK の Revoke-MgUserSignInSession コマンドレットを挙げています。この失効を行わないと、すでにサインイン済みのユーザーは登録を求められないまま残ります。
猶予期間の扱いも把握しておきましょう。Microsoftの公式ドキュメントによれば、セキュリティの既定値群は2019年10月22日以降に作成されたテナントでは有効になっている可能性があり、新しいテナントでは既定で有効・保護が適用されるまで24時間の猶予期間があります。一方で「2024 年 7 月 29 日以降、新しいテナントと既存のテナントでは、ユーザーが MFA に登録するための 14 日間の猶予期間が削除されます。」とされており、登録の猶予は縮む方向にあります。さらに「2026 年 7 月 1 日以降、新しい Microsoft Entra テナントはすべて、セキュリティの既定値の一部としてデバイス コード フローをブロックします。」とも記載されています。「前に確認したときはこうだった」が通用しない領域なので、実施前に公式で現在の挙動を確認してください。
補足：認証方法には強さの差がある
Google Workspaceの管理者向けヘルプ「2 段階認証プロセスでビジネスを保護する」は、「2段階認証プロセスの適用は、任意または必須にすることができます。管理者アカウントや重要なビジネス情報を扱うユーザーに対して、2段階認証プロセスを必須にすることをおすすめします。」としています。管理者から必須にする、という考え方はここでも同じです。
方法の優劣についても明記があります。同ヘルプは「セキュリティ キーは 2 段階認証プロセスの認証要素として最も安全度が高い」とし、「テキスト メッセージはおすすめしません」としています。「とりあえずSMSで有効化した」状態は、無効よりは良いが最善ではないという位置づけです。管理者アカウントについては、セキュリティキーやパスキーへの移行を検討する価値があります。
設定②：管理者権限を減らし、ID発行・削除の手続を決める
IPAのガイドライン第4.0版は、取組3(5)①「IDアクセス制御」で次の2つを挙げています。まずID管理です。
「●ユーザー ID 及び管理者 ID の発行・変更・削除の手続を定める
ユーザー ID や管理者 ID（管理者権限を保持する ID）を漏れなく管理し、不正アクセスの被害等を防止するために、ID の発行から削除までを管理するプロセスを定め、必要最小限の割り当てとなるようにしましょう。また、共有 ID はなるべく使わないようにし、やむを得ず使う場合は共有 ID を利用したユーザーを特定可能とするような仕組みを整備して規定の通り運用しましょう。」
次にアクセス権です。
「●アクセス権の管理ルールを定める
従業員の異動や退職等に伴う権限の変更・削除漏れ、特定役職員等への権限集中によるシステムの不正利用や権限濫用の被害を防止するために、事業所やフロアの入室、システムのアクセス権限を見直すルールを定め、権限の付与状況を管理しましょう。また、アクセス権限の運用や利用状況を監視する仕組みを整備しましょう。」
この2つを、SaaSの管理画面での作業に落とすと次の4手になります。
作業場所は、Google Workspaceなら管理コンソールの「ディレクトリ ＞ ユーザー」から管理者ロールで絞り込む形、Microsoft 365なら Microsoft Entra 管理センターのロールの割り当てが入口になります(画面名は改定されるため、実際のメニュー名は自社の管理画面でご確認ください)。手順は次の4手です。
- 管理者一覧を書き出す。まず人数を数えます。この数がそのまま「乗っ取られたら終わる入口」の数です
- 「なんとなく管理者」を外す。導入時に全員を管理者にした、退職者の権限が残っている、テスト用に付けたまま——このいずれかが出てくることが多い箇所です
- 共有IDを棚卸しする。
info@やsupport@のような共有アカウントは、IPAが言う「利用者を特定可能とするような仕組み」がないまま運用されがちです。個人アカウントからの委任(デリゲート)機能に置き換えられないか検討します - 付与と削除の手続きを1枚に書く。誰が申請し、誰が承認し、いつ削除するか。この文書がないと、担当者が変わった瞬間に運用が止まります
管理者アカウントの扱いには、もう一段の工夫があります。Microsoftの公式ドキュメントは、管理者向けの推奨事項として「管理者の MFA の回数を大幅に減らすために、管理タスクと標準の生産性タスク用に個別のアカウントを用意してください。」としています。日常のメールやチャットは通常アカウント、管理画面の操作は管理者専用アカウント、という分離です。日常業務で使うアカウントは不審なメールを受け取る機会が多いため、管理権限をそこから切り離しておく意味があります(この評価は編集部のものです)。
参考までに、Microsoftのセキュリティの既定値群では、グローバル管理者、アプリケーション管理者、認証管理者、請求管理者、クラウド アプリケーション管理者、条件付きアクセス管理者、Exchange 管理者、ヘルプデスク管理者、パスワード管理者、特権認証管理者、特権ロール管理者、セキュリティ管理者、SharePoint 管理者、ユーザー管理者、認証ポリシー管理者、アイデンティティガバナンス管理者の各役割について、登録完了後はサインインのたびに多要素認証の実行が必要とされています。「請求管理者」や「ヘルプデスク管理者」まで含まれている点は見落とされがちで、経理や庶務の担当者が該当している場合があります。
権限の見直しは、入退社の手続きと一体で回すと漏れません。台帳の作り方と退職時の正しい順番は入退社でSaaSアカウントを取りこぼさない手順にまとめています。
設定③：外部共有リンクの既定を締める
IPAの6か条「４．共有設定を見直そう！」は、対策例として「ウェブサービス、ネットワーク接続の複合機・カメラ、ハードディスク（NAS）などの共有範囲を限定する。」を挙げています。SaaS時代のこの項目は、ほぼファイル共有とゲスト招待の既定値を指します。
ここで押さえるべきなのは、「外部共有」と「リンク共有」が別の設定であることです。混同すると、必要な取引先との共有まで止めてしまい、結局担当者が個人のクラウドストレージを使い始めます。
| パターン | 設定の内容 | 向く組織 | 注意点 |
|---|---|---|---|
| A: 外部共有をオフ | 組織外のユーザーとは共有できない | 外部とファイルをやり取りしない部署、機微情報を扱う組織単位 | 全社適用すると業務が回らず、別ツールでの迂回を招く |
| B: 許可ドメインのみ | 信頼できる(許可されている)ドメインとのみ共有を許可 | 取引先が固定的な企業 | 新規取引のたびに申請が必要。運用担当を決めておく |
| C: 招待は可・不特定リンクは不可 (実務での落としどころ) |
メールアドレス指定の招待は許可し、「リンクを知っている全員」は禁止 | 多くの中小〜中堅企業 | 既存の共有リンクは自動では消えない。棚卸しが別途必要 |
A/B/Cという区分の名称と「向く組織」の評価はjisalab編集部の整理です。各社の公式資料に同じ区分があるわけではありません。設定できる粒度は製品とプランで異なります。
Google Workspaceの設定場所は、管理者ヘルプによると管理コンソールの「メニュー アイコン ＞ アプリ ＞ Google Workspace ＞ ドライブとドキュメント ＞ 共有設定 ＞ 共有オプション」です。同ヘルプは、管理者が「ユーザーが Google ドキュメント、スプレッドシート、スライド、サイト、マイマップ、共有ドライブのファイルやフォルダを組織外のユーザーと共有できるかどうかを管理できます」としており、外部共有をオフにした場合は、招待・リンク共有・メール添付のいずれもできなくなるとしています。許可リストについては「信頼できる（許可されている）ドメインとのみファイル共有を許可することができます」とされ、あわせて「許可リストに登録されている特定のドメインのみとファイルを共有することはできません。すべての信頼できるドメインが対象になります」という制約も明記されています。「この部署はA社とだけ」という細かい切り分けは、許可リスト単体ではできないということです。
Googleはこの用途に「信頼ルール」を用意しており、公式ヘルプは、詳細なポリシーを作成してドライブのファイルにアクセスできるユーザーを制御でき、内部・外部のユーザーとの間で共有できるユーザーのファイル、ファイルを受信できるユーザー、共有ドライブに招待できるユーザーを指定できるとしています。許可リストがドメインを条件にするのに対し、こちらは共有する側・受け取る側のユーザーを条件にする形です(どこまで細かく指定できるかは公式でご確認ください)。ただし対応エディションは Frontline Plus / Enterprise Standard / Enterprise Plus / Education Standard / Education Plus / Enterprise Essentials Plus に限られ、中小企業がよく使う Business 系は含まれていません。「やりたいことは製品にあるが、自社のプランでは使えない」という形で詰まりやすい箇所なので、検討の前にエディションを確認してください。
既存の共有リンクは、設定変更だけでは片づかない
設定を変えるだけでは足りない点が1つあります。既存の共有リンクは、設定変更で自動的に無効になるとは限りません。作業としては、(1)既定値を締める、(2)現在の外部共有を一覧で出して棚卸しする、の2段構えが必要です。
(2)の一覧化は、機能名とエディション要件を先に確認しておかないと空振りします。Google Workspaceの場合、公式ヘルプ「ファイルの共有について調査する」は、セキュリティ調査ツールの「データソース」メニューから「ドライブのログのイベント」を選ぶ手順を示しています。結果の表には「ファイルが外部と共有された日時、ドキュメント ID、ドキュメント タイプ、公開設定、タイトル、イベントタイプ（ユーザー アクセスの変更など）、アクターのユーザー名、ドキュメントの所有者」が表示され、表の上部の「すべてエクスポート」でマイドライブに保存できます。ただしこのツールも対応エディションが限られ、Frontline Standard / Frontline Plus / Enterprise Standard / Enterprise Plus / Education Standard / Education Plus / Enterprise Essentials Plus / Cloud Identity Premium が対象です。
つまり、Business 系のプランでは「既存の外部共有を一覧で出す」こと自体が標準機能では難しいのが実情です。その場合の現実解は、(a)部署ごとに担当者へ自分の共有を点検してもらう、(b)重要フォルダに絞ってオーナーが手作業で確認する、のどちらかになります。全件棚卸しを前提に計画を立てると、初日に止まります。
一覧化ができない環境で手がかりになるのが、日常画面の表示です。別のヘルプ「組織の外部共有を管理する」は、組織外のユーザーが所有または組織外と共有されているファイルには、既定で「外部」の警告インジケーターが表示されるとしています。消さずに残しておくのが実用的です。
Microsoft 365(SharePoint / OneDrive)の場合
Microsoft環境も考え方は同じで、設定場所はSharePoint 管理センターの「ポリシー」＞「共有」です。公式ドキュメントによると、「外部共有」の共有レベルは次の4段階から選びます。
| オプション(公式表記) | 内容 |
|---|---|
| すべてのユーザー | リンクを持つすべてのユーザーが認証なしでアクセスできる。有効期限の強制や、表示のみへの制限を設定できる |
| 新規および既存のゲスト | 職場・学校アカウントかMicrosoftアカウントでのサインイン、または確認コードの入力を求める |
| 既存のゲスト | ディレクトリに登録済みのゲストのみと共有できる |
| 組織内のユーザーのみ | 外部共有を無効にする |
オプション名と内容はMicrosoft Learnの記述にもとづく要約です(表の形は編集部の整理)。同ドキュメントは、OneDriveの設定はSharePointより厳しくはできるが緩和はできないこと、サイトごとに組織と同じかより制約的な設定を持てること、外部共有をオフにして後で有効にするとゲストがアクセスを回復することも記しています。ドメインを絞りたい場合は「その他の外部共有設定」の「ドメインごとに外部共有を制限する」があり、最大5,000ドメインを指定できます。
ドメインの一覧指定は、Google・Microsoftのどちらでもできます。違いは粒度の下げ方で、Googleは「この部署はA社とだけ」に相当する制御を信頼ルール(対応エディション限定)で行い、Microsoftはサイト単位の制限を別に用意しています。組織全体のドメイン一覧だけで運用しようとすると、どちらの製品でも同じ壁に当たります。また、リンクの既定の種類(「特定のユーザー」「組織内のユーザーのみ」「リンクを知っているすべてのユーザー」)も別に設定できます。「リンクを知っているすべてのユーザー」は、外部共有設定が「すべてのユーザー」のときにだけ選べるため、上位の設定を締めれば下位も自動的に絞られます。
棚卸しの優先順位は、1つ目に退職者が作成した共有リンク、2つ目に数年前のプロジェクトフォルダ、3つ目に「一時的に」共有した見積・契約関連の順が効率的です(この順序は編集部の判断です)。いずれも作成時の目的がすでに終わっており、消しても業務影響が出にくいためです。
設定④：ログを取り、「見る日」を決める
IPAのガイドライン第4.0版は、取組3＞(5)＞③プラットフォームセキュリティの中で、次の対策を挙げています。
「●情報機器及びシステムに関するログを取得し、異常を検知するため、定期的にレビューを行う
情報機器や情報システムに対する不審なアクセスを把握し、サイバー攻撃の予兆を検知して被害を防止するため、通信ログや認証ログを取得・保管するとともに、ログの改ざん防止を行った上で、定期的にレビューを行いましょう。」
SaaSの場合、ログの取得自体は事業者側で行われていることが多く、自社の仕事は「見られる状態にすること」と「見ること」になります。まず、自社のログが何日残るのかを数字で押さえるところから始めます。
保持期間は製品とライセンスで大きく変わります。Microsoft 365を例にとると、公式ドキュメントは次のように整理しています。
| 区分 | 監査ログの保持期間 | 備考 |
|---|---|---|
| 監査 (標準) | 180日間 | 既定で有効。「レコードは 180 日間保持されます。つまり、過去 6 か月以内に発生したアクティビティを検索できます」 |
| 監査 (プレミアム) | 最大1年間／条件つきで10年間 | Microsoft Entra ID・Exchange・OneDrive・SharePoint の監査レコードは既定で1年間。10年保持には別途アドオンライセンスが必要 |
表はMicrosoft Learnの記述をもとにした編集部の整理です。同ドキュメントは、監査 (標準) の既定の保持期間が90日から180日に変更され、2023年10月17日より前に生成されたログは90日間保持されることも記しています。なお監査 (プレミアム) は上位のライセンスが前提になるため、自社で使えるかは公式のサブスクリプション要件でご確認ください。
Google Workspaceも公開しています。管理者ヘルプ「データの保持期間とタイムラグ」によれば、管理・ログイン(ユーザー)・ドライブ・トークン・デバイスなどの各ログイベントは「6 か月」、Vaultのログイベントは「期限なし」です。注意が要るのは「メールログの検索」で、こちらは「30 日」しかありません。
この差が、点検の間隔を決めます。6か月のログなら月1回の点検で十分に遡れますが、メールログの30日は、月1回だと前回分がぎりぎり消えます。迷惑メールの誤配送や不審な転送設定を追う可能性があるなら、そこだけ2週間に1回にするか、必要な期間をエクスポートして残す運用に切り替えてください。編集部の目安は「そのログの保持期間の半分より短い間隔で見る」です。180日なら月1回、30日なら2週間に1回、という当てはめになります。
そのうえで、次の3点を決めます。
- 保持期間と書き出し可否を台帳に控える。上の例のように、同じ製品でもライセンスで期間が変わります。事故が起きてから「ログが残っていない」と気づくのが最悪の展開です
- 見る項目を3つに絞る。全件を追うのは現実的ではありません。編集部としては「管理者権限の変更」「見慣れない場所からのサインイン成功」「外部共有の新規作成」の3つを勧めます(この選定は編集部の判断です)
- 見る日を決める。月次の締め処理と同じ日に15分、で構いません。担当者を1人決め、見た結果(異常なしを含む)を残します
点検が年1回だと、前回から今回までの記録がすでに消えている可能性があります。上で示した「保持期間の半分」の目安は、そのための当てはめです。
どこまでが自社の仕事か：責任の分かれ目
第4.0版は第2部 実践編「4. より強固にするための方策 (5) クラウドサービスの情報セキュリティ」(p.56〜)の③クラウドサービスのセキュリティ対策として、次の2つの観点を挙げています。この節は必須の取組ではなく「より強固にするための方策」として置かれている点も、あわせて押さえてください。
「●クラウドサービス事業者のセキュリティ対策を把握し、自社のセキュリティに関する期待を満たしたサービスを利用する。
●利用者である自社の役割・責任を把握し、自社でしかできない対策を的確に実行する。」
同ガイドラインは、詳細については「中小企業のためのクラウドサービス安全利用の手引き」（付録７）のクラウドサービス安全利用チェックシートの 15 項目を参照し、自社の目的や運用計画などに適したクラウドサービスを利用するよう案内しています。
この2つの観点は、実務では性質が違います。1つ目(事業者の対策の把握)は導入前にしかできない選定の話で、2つ目(自社でしかできない対策)は導入後にいつでもできる設定の話です。すでに使っているSaaSについては、1つ目をやり直すことはできません。手が届くのは主に2つ目であり、そちらは今日から着手できます。この記事が設定に絞っている理由がここにあります。ただし完全に切り分けられるわけではありません。監査ログの保持期間のようにプランで決まる項目は、1つ目(選定)の話でもあります。
着手から完了までの順番と所要時間
| 順 | 作業 | 目安 | 飛ばすとどうなるか |
|---|---|---|---|
| 0 | 緊急用アカウントの確保と、レガシー認証で動いている機器・アプリの洗い出し | 30〜60分 | 管理者全員が管理画面に入れなくなる。複合機のメール送信が止まる |
| 1 | 管理者アカウントに多要素認証を適用 段階適用ができる製品(Google Workspaceなど)のみ。テナント一括の製品では、この工程を6と合流させる |
30分 | 被害が最大のアカウントが最後まで無防備なまま残る |
| 2 | 管理者一覧を出し、不要な管理者権限を外す | 60分 | 入口の数が減らず、MFAの効果が薄まる |
| 3 | 外部共有の既定値を変更(招待は可・不特定リンクは不可) | 30分 | 意図しない公開リンクが増え続ける |
| 4 | 既存の外部共有を棚卸しする 一覧化できるかはプラン次第(対象エディションは設定③に列挙。上位・下位の関係ではないため、自社のエディション名で確認する)。使えない場合は部署ごとの自己点検か、重要フォルダに絞った確認に切り替える |
一覧化できる場合は60〜120分／できない場合は部署展開のため数日 | 過去に作られたリンクが生き続ける |
| 5 | 監査ログの保持期間を確認し、月次の点検日を決める | 30分 | 事故のときに何が起きたか追えない |
| 6 | 全社へ多要素認証を適用(事前告知と登録期間を設ける) テナント一括の製品では、管理者分もここで同時に適用される |
告知から1〜2週間 | 問い合わせが集中し、現場の反発で計画が止まる |
この表は編集部が作業工程から立てた目安であり、実測値ではありません。所要時間は利用者数、サービス数、既存設定の状態によって大きく変わります。0番を最初に置いているのは、多要素認証の適用で最も起きやすい事故が管理者自身のロックアウトとレガシー認証の停止であるためです。
複数のSaaSを使っている場合は、「そこが破られたら他も破られる」サービスから着手します。具体的には、パスワード再設定メールを受け取るメール環境と、シングルサインオンの起点になっているサービスです。この2つが守られていないと、他のサービスをいくら固めても迂回されます。
日本の会社での勘所
日本の中小〜中堅企業でこの作業が止まる原因は、技術ではなく体制と慣行にあります。よくある4つを挙げます。
1つ目は兼任の情シスです。総務や経理の担当者が「PCに詳しい人」として管理者を兼ねている職場では、設定変更で何かが止まったときに自分で復旧できるか不安があり、着手そのものが遅れます。だからこそ、緊急用アカウントの確保とレガシー認証の洗い出しを先に置く順番が効きます。戻せる状態を作ってから触る、という段取りが心理的なハードルを下げます。
2つ目は複合機とメールです。スキャンした書類を社内へメール送信する設定は、多くの職場で古い認証方式のまま動いています。Microsoftの公式ドキュメントも、レガシー認証のブロックに関連して多機能機器やアプリケーションのメール送信設定の案内へリンクしています。「MFAを有効にしたらスキャンが送れなくなった」は、事前の洗い出しで防げる止まり方です。事前の洗い出しに、必ず複合機を含めてください。
3つ目は私物スマートフォンでの多要素認証です。会社が業務用端末を配っていない場合、認証アプリを私物端末に入れてもらう形になり、断られることがあります。強制すると労務面の摩擦になりますし、そもそも本人が退職すれば端末ごと失われます。ここで注意が要るのは、「セキュリティキーを配れば解決する」とは限らない点です(設定①で見たとおり、既定値群の案内にセキュリティキーは出てきません)。「代替手段を用意する」を計画に書く前に、自社の製品で何が選べるかを確認してください。
4つ目は業務委託・派遣・グループ会社の扱いです。雇用関係のない人が業務システムに入っている状態は珍しくありませんが、権限の見直しの対象から漏れがちです。IPAの10大脅威2026【組織編】で2位に「サプライチェーンや委託先を狙った攻撃」が入っていることを踏まえると、ここは優先度の高い棚卸し対象です。契約終了日を台帳に持ち、終了日に権限を落とす運用まで決めておくと漏れません。なお、外部の事業者に個人データの取扱いを伴う業務を任せる場合は、委託先の監督など別の論点が生じます。判断に迷う場合は、自社の規程および弁護士等の専門家にご確認ください。
- □ 対象を1サービスに絞る(まずはメール環境か、シングルサインオンの起点になっているサービス)
- □ 緊急用アカウントを用意する(通常業務では使わない。Microsoft環境ならクラウド専用の緊急アクセス アカウント2つ、Google環境なら複数の特権管理者アカウントを別のユーザーが管理する形が公式の推奨)
- □ Google環境では、特権管理者のバックアップコードを発行してオフラインで保管する(適用前に済ませる、という順番は編集部の推奨)
- □ レガシー認証で動いている機器・アプリを洗い出す(複合機のメール送信、古い業務アプリ、バッチ処理)
- □ 自社の製品で「管理者だけ先に適用」ができるかを確認する(Google Workspaceは組織部門・グループ単位で可能／Microsoft 365のセキュリティの既定値群はテナント一括で、範囲指定には Microsoft Entra ID P1 以上が必要)
- □ 段階適用ができるなら、管理者アカウントに先に多要素認証を適用する。できないなら「事前告知 → 準備 → 一括で有効化」の段取りに切り替える
- □ 管理者一覧を書き出して人数を数え、導入時のまま・退職者・テスト用の権限を外す。あわせて管理タスク用と日常業務用のアカウント分離、共有ID(info@ など)の棚卸しも検討する
- □ ID の発行・変更・削除の手続き(申請者・承認者・削除の契機)を1枚に書く
- □ 外部共有の既定値を決める(招待は可・「リンクを知っている全員」は不可、が多くの企業の落としどころ)
- □ 自社のプランで外部共有の一覧化ができるかを確認し(対象エディションは設定③に列挙。Business系は含まれない)、できない場合は部署ごとの自己点検か重要フォルダに絞った確認に切り替える
- □ 監査ログの保持期間と書き出し可否を確認し、台帳に控える(例: Microsoft Purview の監査 (標準) は180日間、監査 (プレミアム) は最大1年間。製品とライセンスで異なる)
- □ ログで見る3項目(管理者権限の変更／見慣れない場所からのサインイン成功／外部共有の新規作成)と、月次の点検日・担当者を決める
- □ 業務委託・派遣・グループ会社のアカウントを洗い出し、契約終了日を台帳に持つ
- □ 全社への多要素認証の適用は、事前告知と登録期間を設けてから実施する
- □ 自社の製品で選べる認証方法を確認する(Google Workspaceはセキュリティキー・パスキーが選べる／Microsoftのセキュリティの既定値群で公式が挙げているのはAuthenticatorアプリとOATH TOTPアプリで、セキュリティキーは案内に出てこない)
- □ 私物端末を使えない人がいる場合の手当てを決める(業務用端末の貸与、または条件付きアクセスへの移行の検討)
よくある質問(FAQ)
多要素認証を全社に適用したいのですが、現場の反発が予想されます。どう進めればよいですか?
順番と告知で、摩擦の大半は減らせます。実務的な進め方は、①管理者だけ先に適用して運用上の問題を洗い出す ②想定される問い合わせと回答を用意する ③登録期間を設けて告知する ④期限日に必須化するの4段階です。ただし①ができるかは製品によります。Google Workspaceは組織部門やグループ単位で適用できるので①をそのまま実行できますが、Microsoftのセキュリティの既定値群はテナント一括のため、①は④と合流します(その場合は事前準備と告知の比重が上がります)。管理者で先に試すのは、実際にやってみないと分からない詰まり(複合機が止まる、特定のアプリが対応していない、など)を、被害の小さい範囲で先に踏むためです。告知では「セキュリティのため」だけでなく、本人にとっての意味(自分のアカウントが乗っ取られると、社内の全員に自分名義で不審なメールが飛ぶ)を書くと納得が得られやすくなります。なお、Google Workspaceの管理者ヘルプも、まず管理者アカウントや重要なビジネス情報を扱うユーザーに対して必須にすることを勧めています。
うちはGoogle Workspace の Business プランです。この記事の内容は全部できますか?
設定①認証と②権限はそのままできます。③共有と④ログは、締めること自体はできますが「調べる」側に制限が出ます。多要素認証(2段階認証プロセス)の適用は、組織部門やグループ単位の指定を含めて行えます(参照した「2 段階認証プロセスを導入する」には対応エディションの限定が記載されていません)。管理者権限の見直しも同様で、外部共有も既定値を締めること自体はできます。制限が出るのは調べる機能のほうです。既存の共有を一覧化するセキュリティ調査ツールも、共有相手を細かく制御する信頼ルールも、対応エディションに Business 系が含まれていません(対象エディションの一覧は設定③に記載しました)。Business プランの現実解は、既定値を締めたうえで、部署ごとの自己点検か重要フォルダに絞った確認で棚卸しを回すことです。ログも同じ考え方で、まず管理コンソールの監査ログで見られる範囲を確認し、横断的な調査やエクスポートが必要になった時点でエディションの見直しを検討します。
予算がありません。無料でどこまでできますか?
この記事の4つの設定は、いずれも多くのサービスで追加費用なしに実施できます。Microsoft Entra IDの「セキュリティの既定値群」は、公式ドキュメントがMicrosoft Entra ID ライセンスの Free レベルを使用している組織を対象に挙げており、追加の費用なしで少なくとも基本レベルのセキュリティを有効にできることを目的としたものです。費用が必要になるのは、条件付きアクセスのような細かい制御(Microsoft Entra ID P1 以上のライセンスが必要)や、監査ログの長期保持など、上位プランでのみ提供される機能を使う場合です。先に無料の範囲で締め、それでも足りない要件が明確になってから上位プランを検討するのが順序として合理的です。プランごとの提供範囲は改定されるため、実施前に各サービスの公式ページでご確認ください。
設定を変えたら業務が止まりました。どうすればよいですか?
止まり方で対応が分かれますが、切り戻す前に、何が止まったかを記録してください。よくあるのは、(1)レガシー認証を使っていた複合機や業務アプリのメール送信が止まる、(2)外部共有を締めたことで取引先がファイルを開けなくなる、(3)管理者が管理画面に入れなくなる、の3つです。(1)は該当機器を先に対応させる(送信方法の変更)ことで解決でき、設定自体を戻す必要はありません。(2)は、全面禁止ではなく「招待は可・不特定リンクは不可」に切り替えることで、多くの場合は業務を保ったまま締められます。(3)は緊急用アカウントで復旧します。「止まったからすべて元に戻す」を選ぶと、次に着手するときの心理的コストが跳ね上がります。止まった箇所を1つずつ潰す方が、結果的に早く終わります。
あわせて読みたい
複合機や業務システムに加えて、SaaSから自社ドメインの名前で送るメールの認証も確かめるなら → SaaSから送るメールが迷惑メールに入る問題を直す手順
海外SaaSに個人データを預ける前の確認なら → 海外SaaSに個人データを預ける前のチェック
出典・参考
- 独立行政法人情報処理推進機構(IPA)「中小企業の情報セキュリティ対策ガイドライン」第4.0版(2026年3月)より、「情報セキュリティ6か条」、「５分でできる！情報セキュリティ自社診断」(解説編) Part 1 の No.3・No.4 の対策例、取組3＞(5)＞①(IDアクセス制御)と同＞③(プラットフォームセキュリティ)の各対策、第2部 実践編 4.(2)③アクセス管理の多要素認証の定義、同 4.(5)③クラウドサービスのセキュリティ対策と付録7への案内(引用箇所はいずれも本文に明記)｜IPA(PDF: sme_guideline_v4.0.pdf／2026年9月6日にPDF原文を取得し逐語で確認)
- IPA プレス発表「「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開」(2026年3月27日公開／「バックアップを取ろう!」を新たに追加し情報セキュリティ6か条とした旨)｜IPA(2026年9月6日確認)
- IPA「情報セキュリティ10大脅威 2026」【組織編】(2026年1月29日公開／1位〜10位、約250名の「10大脅威選考会」による審議・投票)｜IPA(2026年9月6日確認)
- Microsoft Learn「Microsoft Entra ID のセキュリティの既定値を構成する」(ms.date 2025-07-21／2026年8月16日更新表記)より、基本的なコントロール、対象者、猶予期間と適用時期の変更、レガシ認証の警告、MFAが毎回必要となる管理者ロール、緊急アクセス アカウント2つの推奨、有効化の手順と既存トークンの取り消し、認証方法と「組織のメソッドを無効にしないでください」の警告、Microsoft管理の条件付きアクセス ポリシー、条件付きアクセスとの比較表(引用箇所は本文に明記)｜Microsoft Learn(2026年9月6日に原文を取得し逐語で確認)。本文で引用した「99.9% 以上」「99.2% を超える」はいずれもMicrosoft自身が公表している数値であり、第三者機関による検証値ではありません
- Google Workspace 管理者ヘルプ「2 段階認証プロセスを導入する」(組織部門またはグループを選んで一部のユーザーに限定できること、「今すぐ強制」と「指定した日付から適用を有効にする」、「新しいユーザーの登録期間」を1日〜6か月で設定できること)｜Google Workspace ヘルプ(2026年9月6日確認)
- Google Workspace 管理者ヘルプ「ドライブ共有の信頼ルールを作成、管理する」(信頼ルールで指定できる範囲、対応エディション: Frontline Plus／Enterprise Standard／Enterprise Plus／Education Standard／Education Plus／Enterprise Essentials Plus)｜Google Workspace ヘルプ(2026年9月6日確認)
- Google Workspace 管理者ヘルプ「ファイルの共有について調査する」(セキュリティ調査ツールの「ドライブのログのイベント」、検索結果に表示される項目、「すべてエクスポート」、対応エディション: Frontline Standard／Frontline Plus／Enterprise Standard／Enterprise Plus／Education Standard／Education Plus／Enterprise Essentials Plus／Cloud Identity Premium)｜Google Workspace ヘルプ(2026年9月6日確認)
- Google Workspace 管理者ヘルプ「2 段階認証プロセスでビジネスを保護する」(適用は任意または必須にできること、管理者アカウント等への必須化の推奨、セキュリティ キーが最も安全度が高いこと、テキスト メッセージは推奨されないこと)｜Google Workspace ヘルプ(2026年9月6日確認)
- Microsoft Learn「Microsoft 365 で SharePoint と OneDrive の共有設定を管理する」(ms.date 2026-06-30)より、共有設定の場所、外部共有オプション4種、OneDriveは厳格化のみ可であること、オフ→再オンでゲストがアクセスを回復すること、ドメインごとの制限、リンクの既定オプション(引用箇所は本文に明記)｜Microsoft Learn(2026年9月6日に原文を取得し確認)
- Microsoft Learn「Microsoft Purview の監査ソリューションについて説明します」(ms.date 2026-05-18)より、監査 (標準)／(プレミアム) の保持期間と、既定が90日から180日へ変更された経緯(引用箇所は本文に明記)｜Microsoft Learn(2026年9月6日に原文を取得し確認)
- Google Workspace 管理者ヘルプ「データの保持期間とタイムラグ」(各ログイベントのデータ保持期間: 管理／ユーザー／ドライブ／トークン／デバイス等は6か月、メールログの検索は30日、Vaultのログイベントは期限なし)｜Google Workspace ヘルプ(2026年9月6日確認)
- Google Workspace 管理者ヘルプ「管理者アカウントのセキュリティに関するおすすめの方法」(複数の特権管理者アカウントを別のユーザーが管理すること、特権管理者に専用アカウントと日常業務用アカウントの2つを付与すること、セキュリティキーまたはスマートフォンを紛失した場合のバックアップコード)｜Google Workspace ヘルプ(2026年9月6日確認)
- Google Workspace 管理者ヘルプ「組織の外部共有を管理する」(外部共有のオン/オフで制限される範囲、信頼できるドメインとのみ共有を許可できること、許可リストの特定ドメインのみを対象にはできないこと、組織外と共有されているファイルの「外部」警告インジケーター)｜Google Workspace ヘルプ(2026年9月6日確認)
- 本記事は一般的な業務手順の解説であり、法令・ガイドラインの解釈を確定させるものではありません。個別の適法性の判断は、自社の規程および弁護士等の専門家にご確認ください。各サービスの設定項目名・既定値・プランごとの提供範囲は変更されるため、実施前に必ず最新の公式ドキュメントでご確認ください。
本記事に登場する製品名・ロゴは各社の商標または登録商標です。掲載の図解はjisalab編集部が作成したものです。各表の出所は表注に記載しています。
