改めて確認したいGoogle Workspaceのセキュリティ設定チェックリスト

①管理者アカウントを日常業務と分けているか

まず、最初に確認したいのは、管理者アカウントです。特権管理者は、組織全体の設定やユーザー管理に関わる強い権限を持ちます。そのため、一般の利用者以上に慎重な保護が必要です。

管理者アカウントは共用せず、各担当者が個別のアカウントで操作する構成にします。また、Googleは特権管理者用のアカウントと、メールや日常業務に使うアカウントを分離することを推奨しています。特権管理者のアカウントには、管理作業が必要なときにログインする運用にすることが重要です。

あわせて、担当業務に対して権限が過剰になっていないかを確認します。Google Workspaceにはカスタムロールという機能があるため、ユーザー管理などの作業を担当する人には、必要な管理者ロールを割り当てることを検討してください。

一方で、特権管理者が1人だけでは、その担当者がログインできなくなった際の復旧に備えられません。異なる担当者が管理する複数の特権管理者アカウントを用意し、保護と復旧の両方を考える必要があります。

ここまでの説明を踏まえ、以下のチェックリストを確認してみてください。

• 管理者アカウントを共用していない
• 担当業務に必要な権限を割り当てている
• 特権管理者用と日常業務用のアカウントを分けている
• 別の担当者による復旧に備えている

②2段階認証を利用者任せにしていないか

アカウントへの不正ログイン対策として、まず確認したいのが2段階認証です。パスワードに加えて本人確認を行うことで、パスワードが第三者に知られた場合の保護を強化できます。

昨今、日本企業で顧客情報や認証情報が奪われる事件が相次いでいます。AIの影響により効率的に攻撃が実施できるようになっている背景から、「ある一定規模の企業だけが狙われる」という常識が揺らぎつつあります。少なくとも、2段階認証は企業として必須の設定にする必要があると考えています。

また、認証方法によって保護の特性も異なります。管理者や重要な情報を扱う利用者には、フィッシングへの耐性があるパスキーやセキュリティキーの利用を検討してください。

強制適用を進める際には、事前の案内と登録状況の確認も必要です。新規ユーザーには登録の猶予期間を設定できるため、入社時の手順と合わせて設計します。認証手段を失った場合の対応も含め、利用者が業務に戻れるところまで準備する必要があります。

• 2段階認証の強制適用を確認した
• 未登録者と適用対象を把握している
• 重要なアカウントの認証方法を確認した
• 入社時の登録と認証手段を失った際の対応を定めている

③ドライブの共有相手と権限を把握しているか

ログインを保護していても、ファイルを組織外へ自由に共有できる状態では、情報が意図しない相手に渡るリスクが残ります。まず確認したいのは、管理コンソールで、自社の業務に合った共有制限を設定できているかです。

外部共有は、組織全体に同じルールを適用するだけでなく、部門やグループに応じて許可する範囲を変えられます。外部との共同作業が必要な対象を整理し、必要に応じて許可リストに登録したドメインとの共有に限定してください。

共有ドライブについても、外部ユーザーとの共有や、共有ドライブのメンバー以外へのファイル共有を制限できます。特に注意したいのが、外部ユーザーに「編集者」権限を付与した場合です。標準機能では、編集者はさらに別の第三者へファイルを共有できてしまうため、管理者の目の届かないところで情報が拡散する二次共有のリスクがあります。社内資料と取引先との共同作業用資料で、用途に合った共有制限を設定することが重要です。

• 外部共有の許可・禁止を、自社の方針に合わせて設定している
• 外部共有を許可する部門・グループを必要な範囲に限定している
• 共有先ドメインの制限が必要か判断し、必要な場合は許可リストを設定している
• 共有ドライブの外部共有と、メンバー以外への共有を用途に応じて制限している

④外部アプリに何を許可したか確認しているか

Google アカウントで外部サービスにログインしたり、業務アプリを連携したりする場合は、そのアプリに渡している権限も確認対象です。プロフィール情報を使うログインと、メールやファイルのデータへのアクセスでは、許可する内容が異なります。

管理コンソールのAPI制御では、設定済みのアプリや、データにアクセスしたアプリを確認できます。利用者数、要求するサービス、OAuthスコープなどを見ながら、業務上の必要性とアクセス範囲を照合します。OAuthスコープは、アプリがどのデータにどのような操作を求めるかを示すものです。

アプリのアクセス設定には、信頼できる、制限付き、特定のGoogleデータ、ブロックなどの選択肢があります。信頼できる設定は広いアクセスを認めるため、必要な範囲を指定できるかも検討してください。

既存アプリの確認と同時に、未設定のアプリを接続しようとした際の扱いも決めます。新しいサービスの導入時に、利用目的とアクセス権を確認する手順を設けることが大切です。

• データにアクセスしているアプリを確認した
• 利用目的と要求する権限を照合した
• 不要なアプリのアクセスを見直した
• 未設定のアプリを利用する際の扱いを決めている

⑤メール認証と自動転送を確認しているか

メールの対策では、自社ドメインのなりすまし対策も確認します。SPFは送信を許可したサーバーを示し、DKIMは電子署名によってメールを認証する仕組みです。DMARCは、認証に失敗したメールの取り扱いを受信側に示すために使います。

SPFを確認するときは、Google Workspace以外の送信元も調べてください。メール配信サービスや営業支援システムなどから自社ドメインで送信している場合は、それらも含めた設定が必要です。

DMARCは、レポートによる監視から段階的に導入します。正規のメールが認証を通過しているかを確認したうえで、隔離や拒否へ進める手順が示されています。

受信メールの自動転送も確認対象です。外部への自動転送は情報持ち出しにつながるため、業務上の必要性を判断します。POP・IMAPについても、必要な利用者に限定することが推奨されています。

• 自社ドメインの送信元を把握している
• SPF・DKIM・DMARCの設定と認証結果を確認した
• 自動転送の必要性を確認した
• POP・IMAPの利用範囲を確認した

⑥端末上の業務データまで管理しているか

アカウントと共有の次に確認したいのが、アクセスに使う端末です。Google エンドポイント管理では、会社所有の端末や私物端末に対して、画面ロックやパスワードなどを管理できます。高度な管理では、暗号化や侵害された端末のブロックなども確認対象になります。

紛失時や退職時には、業務アカウントのデータを削除する操作と、端末全体をワイプする操作を区別してください。利用できる操作は端末や管理方式によって異なるため、管理コンソールから何ができるのかを事前に把握します。

また、Enterprise以上のエディションであれば、コンテキストアウェア アクセスにより、IPアドレスや端末のセキュリティ状態などに基づくアクセス制御も検討できます。会社端末と私物端末、それぞれの利用条件を整理し、自社の働き方に合わせて設定してください。

• 会社端末と私物端末の管理方針を決めている
• 画面ロックなどの適用状況を確認した
• 紛失時に実行できる操作を把握している
• アクセス制御機能の対応条件を確認した

⑦退職時の対応をパスワード変更で終えていないか

退職時には、アクセスを止める作業と、必要な業務データを残す作業の両方が必要です。管理者向けの手順には、パスワードの変更だけでなく、ログインCookieのリセット、アプリのアクセス権の確認、端末上の業務データの削除などが含まれています。

つまり、パスワードを変更したことだけで対応完了とは判断できません。ログイン状態、アプリ連携、端末など、確認対象を手順に沿って点検する必要があります。

アカウントを削除する場合は、残す必要があるデータを事前に移行します。アクセス停止とデータの引き継ぎを、それぞれ確認できるようにしてください。日常的に共有ドライブへチームの資料を保存することも、退職後に業務資料を残すための選択肢です。

• アクセス停止の担当者と実施時点を決めている
• ログイン状態、アプリ連携、端末への対応を確認した
• 削除前に必要なデータの引き継ぎを確認した
• 実施した作業を記録している

⑧異常の検知・対応とログの保存体制を整えているか

異常を把握するための通知やログ確認を、日常の運用に組み込むことが重要です。不審なログインや管理者による設定変更を確認できるよう、アラートの設定と通知先を見直してください。誰が確認し、どこへ連絡するかまで決めておく必要があります。

また、ログは無期限に確認できるわけではありません。管理者、ドライブ、ユーザーのログイベントの保存期間は180日、メールログ検索は30日です。ログやレポートには反映の遅れもあるため、確認できる期間とタイミングを把握しておく必要があります。

標準の保存期間を超えて調査・監査に利用する場合は、保存期間が過ぎる前に、必要なログを別の保存先へ継続的に書き出す仕組みを用意してください。対応エディションでは、ログや利用状況レポートをBigQueryに書き出せます。ただし、すべてのデータが対象になるわけではないため、契約中のエディションと必要なログの対応状況を確認する必要があります。

書き出しを設定した後も、必要なログが保存されているか、保存先の有効期限が自社の保存方針と合っているかを確認します。調査時に利用できるよう、閲覧・削除権限も整理しておくことをお勧めします。

アカウントの侵害が疑われる場合は、アクセスの停止や不正な操作・設定の調査につなげます。通知の確認からログの保全、調査、対応までを一続きの手順として準備しておくことが大切です。

※Google Workspaceの利用ログをBigQueryに出力する手順はコチラの記事をご参考ください。

• 重要なアラートの通知先と、確認する担当者を決めている
• 調査に必要なログの種類と、標準の保存期間を把握している
• 自社に必要な保存期間を決め、長期保存が必要なログの書き出しを設定している
• 書き出し先への保存状況、有効期限、閲覧・削除権限を確認している
• 不審な動きを見つけた際のアクセス停止・ログ保全・調査の手順を用意している

自社の設定を言語化できる状態にすることが重要

ここまでのチェックでは、設定が有効かどうかに加えて、誰に適用されているかも確認してください。外部アプリのアクセス管理では、組織全体と特定の組織部門に異なるポリシーを設定できます。全体の設定だけを見ても、個々の利用者に適用される条件を把握できない場合があります。

共有についても同様です。共有ドライブで外部共有を禁止しても、個別ファイルの外部ユーザーの権限が残る場合があります。後から外部共有を許可するとアクセスが復活するため、共有制限と個別の権限を合わせて確認する必要があります。

点検結果には、設定値、適用対象、例外の理由、確認日を残すことをお勧めします。設定を見直すときに、何のためにその状態にしたのかを判断できるようになるためです。

私は、セキュリティ設定の点検を、導入後の継続的な運用として位置づけることが重要だと考えます。2段階認証の登録状況はどうか。外部共有を誰に認めているか。どのアプリが業務データにアクセスできるか。異常を見つけたときに誰が対応するか。こうした問いに答えられる状態を作ることが、導入後のセキュリティを支える第一歩になるはずです。