本文へ移動

ホーム / 情シス / 第4部 SaaS・社内システム・AI

第4部 SaaS・社内システム・AI・第9章

Google Workspace・Microsoft 365

★★☆ 重要5トピック・面接 3問

会社の基盤になるグループウェアの管理を押さえる。

別のページで開く →

ネットワーク図を読み込んでいます…

9.1管理と共有の設定

用語★★☆ 重要
ひとことで

外部共有・ドライブの権限・データの保持期間を、会社のルールに合わせて設定する。

Google Workspace と Microsoft 365 は、メール・ファイル・カレンダー・チャットがまとまった、会社の情報のいちばん大きな置き場です。管理コンソールの既定の設定のままだと、会社のルールより共有がゆるいことがあるので、最初に見直します。

外部共有の制御

既定は「社内だけ」。外へは相手を指定して共有する自分だけ社内の特定の人社内全員指定した社外の人リンクを知る全員範囲が広いほど、漏れたときの影響が大きい(リンクは転送されると止められない)
共有の範囲と、漏えいしたときの影響
設定考え方例
リンクの共有の既定「リンクを知っている全員」ではなく「社内の人だけ」を既定に外に出すときは相手を指定して共有
社外との共有許可・許可するドメインだけ・禁止 を部署で分ける営業は取引先と共有可、人事は社外共有を禁止
ゲスト(外部ユーザー)招待できる人と、期限を決めるTeams・共有ドライブのゲストを定期的に見直す
共有ドライブ・チームのサイト個人のドライブではなく、組織のドライブに置く退職してもファイルが残る・持ち主が部署になる
機密ラベル・DLPマイナンバー・カード番号などを含むファイルの外部共有を止める・警告する上位のプランの機能のことが多い

設定を変えると、すでに外部に共有しているファイルが急に見られなくなることがあります。まず「外部に共有されているファイル」の一覧を出して影響を確かめ、部署に知らせてから切り替えます。

面接ではこう答える

Google Workspace と Microsoft 365 は、メール・ファイル・カレンダー・チャットがまとまった、会社の情報のいちばん大きな置き場です。管理コンソールの既定の設定は会社のルールよりゆるいことがあるので、最初に見直します。特に、リンクの共有の既定を「社内の人だけ」にし、社外との共有は部署ごとに許可や禁止を分け、ファイルは個人ではなく共有ドライブに置くようにします。設定を変える前に、すでに外部に共有されているファイルを洗い出して影響を確かめます。

ひとことで

メールやファイルを決めた期間残す保持のルールと、誰が何をしたかを記録する監査ログ。

メールやファイルを「何年残すか」と、「誰が何をしたか」の記録をどう残すかを決めます。どちらも、事故や訴訟のときの調査と、監査で使います。

  • 保持:Google Vault・Microsoft Purview の保持ポリシーで、メールやファイルを「何年残すか」「消されても一定期間は残すか」を決めます。訴訟や調査のときは、その人のデータを消えないように固定(リティゲーションホールド)できます。退職者のデータを消す前に、保持のルールに当てはまるか確認します。
  • 監査ログ:ログイン・ファイルの共有と閲覧・管理者の操作・メールの転送の設定などが記録されます。ログを見られる期間はサービスやプランで限られるので、長く残したい場合は SIEM や保管用のストレージに定期的に書き出します。
  • アラート:「メールを外部に自動転送する設定が作られた」「大量のファイルがダウンロードされた」「管理者の権限が付いた」などは通知を受けるようにします。

面接ではこう答える

Google Vault や Microsoft Purview の保持ポリシーで、メールやファイルを何年残すか、消されても一定期間は残すかを決めます。訴訟や調査のときは、その人のデータを消えないように固定するリティゲーションホールドを使います。監査ログには、ログインや共有、管理者の操作、メールの転送の設定などが記録されますが、見られる期間が限られるので、長く残すものは SIEM などに書き出します。外部への自動転送の設定や大量のダウンロードは、通知を受けるようにします。

ひとことで

SPF・DKIM・DMARC で、なりすましメールを防ぎ、自社のメールを届きやすくする。

メールの送信者(From)は簡単に偽れます。送信ドメイン認証は、受け取った側が「このメールは本当にそのドメインから送られたか」を DNS で確かめる仕組みで、SPF・DKIM・DMARC の3つを組み合わせます。Gmail は、すべての送信者に SPF か DKIM を、Gmail 宛てに1日5,000通以上送る送信者には SPF・DKIM・DMARC のすべてを求めています。Yahoo も大量に送る送信者に同じような要件を設けています。設定がないと、自社のメールが迷惑メールになったり、届かなくなったりします。

受信側が、送信元のドメインの DNS を引いて確かめる自社の送信サーバーFrom: example.co.jpDKIM の署名をつける受信サーバーGmail などメールexample.co.jp の DNSSPF・DKIM の公開鍵・DMARC引く① SPF送ってきた IP は許可された送信元か② DKIM署名は正しいか(書き換えなし)③ DMARCSPF か DKIM が合格し、From と一致するか合格受信箱へ不合格p= に従うnone・隔離・拒否DMARC のレポート(rua)は、受信側から毎日 XML で届く
受信側での SPF・DKIM・DMARC の確かめ方
仕組み確かめることDNS の設定の例
SPF送ってきたサーバーの IP が、そのドメインが許可した送信元かexample.co.jp TXT "v=spf1 include:_spf.google.com ~all"
DKIMメールに付いた電子署名が、DNS の公開鍵で正しいか(途中で書き換えられていないか)google._domainkey.example.co.jp TXT "v=DKIM1; k=rsa; p=…"
DMARCSPF か DKIM が合格し、そのドメインが From のドメインと一致(アライメント)しているか。不合格のときの扱いとレポートの送り先_dmarc.example.co.jp TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.co.jp"

下の演習では、Gmail にメールが届かなくなった障害の原因を調べられます。

メールの基本(どのように届くのか)(SRE の解説)

面接ではこう答える

メールの From は簡単に偽れるので、受け取った側が DNS を見て、本当にそのドメインから送られたかを確かめる仕組みが送信ドメイン認証です。SPF は送ってきたサーバーの IP が許可された送信元かを、DKIM はメールの電子署名が正しいかを確かめます。DMARC は、SPF か DKIM が合格し、そのドメインが From と一致しているかを見て、不合格のときの扱いとレポートの送り先を決めます。大手のメールサービスが送信者に設定を求めているので、ないと自社のメールが届かなくなることもあります。

別のページで開く →

障害対応の演習を読み込んでいます…

DMARC はいきなり p=reject にすると、設定の漏れた正規のメールまで届かなくなります。レポートを見ながら段階的に強めます。

レポートを見ながら、少しずつ強める最初送信元の洗い出し自社ドメインで送るもの全部数週間p=noneレポートだけ受け取る直したらp=quarantine一部(pct)から迷惑メールへ最後p=reject受け取り拒否
DMARC のポリシーを強める段階
  1. 送信元を洗い出す:Google Workspace・Microsoft 365 だけでなく、メール配信サービス・CRM・請求書の送信・問い合わせフォームなど、自社のドメインで送っているものをすべて。
  2. SPF:送信元を1つの TXT レコードにまとめる(SPF のレコードは1つだけ)。include などの DNS の参照は合計10回までなので、増やしすぎない。
  3. DKIM:各サービスの管理画面で鍵を作り、指定のセレクタ名で DNS に登録して署名を有効にする(Google Workspace の既定のセレクタは google、Microsoft 365 は selector1・selector2 の CNAME 2つ、など方式はサービスごと)。配信サービスにも自社ドメインで署名させる。
  4. DMARC を p=none で始める:メールの扱いは変えずに、レポートだけを受け取る。
  5. レポートを数週間見て直す:正規の送信元がすべて合格するまで SPF・DKIM を直す。
  6. 段階的に強める:p=quarantine(迷惑メールへ)を一部(pct=)から始め、最後は p=reject(受け取り拒否)へ。メールを送らないドメインは v=spf1 -all と p=reject にする。

rua に届く集計レポートは、受信側(Google・Microsoft など)が1日ごとに送ってくる XML のファイルで、「どの IP から・何通・SPF と DKIM の結果・アライメントの結果」が並んでいます。そのままでは読みにくいので、集計してくれる DMARC のレポートのサービスか、スクリプトで表にします。

レポートの中身判断
自社の正規の送信元で、SPF・DKIM ともに合格問題なし
自社の正規の送信元(配信サービスなど)なのに不合格SPF への追加・DKIM の設定漏れ。強める前に直す
知らない IP から自社ドメインで送られているなりすまし。p=reject にすれば届かなくなる
メーリングリスト・転送で SPF だけ不合格転送では SPF が崩れやすい。DKIM が合格していれば DMARC は合格

レポートの送り先(rua)には大量の XML が届くので、専用のメールアドレスかレポートのサービスを用意し、個人の受信箱に届けないようにします。

この章のまとめ

🖨 まとめシート(印刷・PDF)
  • 管理コンソールでの設定と共有の制御
  • メールの認証(SPF・DKIM・DMARC)

この章のクイズ

面接ではこう聞かれる

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1なりすましメールを防ぐには?

模範回答

自社のドメインになりすましたメールは、SPF・DKIM・DMARC の送信ドメイン認証で防ぎます。SPF で送ってよいサーバーを、DKIM で電子署名を DNS に公開し、DMARC で「From のドメインと一致して合格しなければ拒否する」ことを受信側に伝えます。

進め方は、まず自社のドメインで送っているサービスを洗い出して SPF と DKIM を設定し、DMARC を p=none にしてレポートを見ます。正規の送信元がすべて合格したら quarantine、reject と段階的に強めます。それとは別に、取引先や社長を名乗る似たドメインからのメールは DMARC では防げないので、受信側のメールの検査、外部からのメールに目印を付ける設定、振込先の変更は電話で確かめるといった業務のルールと訓練で補います。

深掘りされたら

  • SPF の DNS 参照が10回を超えたらどうしますか?
  • メールの転送で DMARC が失敗するのはなぜですか?

見られているポイントSPF・DKIM・DMARC と段階的な強化

Q2Google ドライブや OneDrive の外部共有をどう設定しますか?

模範回答

リンクの共有の既定を「社内の人だけ」にし、社外に出すときは相手を指定して共有するようにします。社外との共有の許可は部署ごとに分け、例えば人事は社外共有を禁止、営業は取引先のドメインだけ許可、のようにします。

設定を変える前に、今外部に共有されているファイルの一覧を出して影響を確かめ、部署に知らせてから切り替えます。ファイルは個人のドライブではなく共有ドライブに置いてもらうと、退職しても残ります。外部への大量の共有やダウンロードはアラートで気づけるようにします。

深掘りされたら

  • 「リンクを知っている全員」で共有されたファイルが多数見つかったら?

見られているポイント既定は社内・部署ごとの許可・影響の確認・共有ドライブ

Q3自社のメールが取引先で迷惑メールになると言われました。何を確かめますか?

模範回答

まず受け取った側でメールのヘッダー(Authentication-Results)を見せてもらい、SPF・DKIM・DMARC の結果を確かめます。よくある原因は、メール配信サービスや請求書の送信など、新しく使い始めた送信元が SPF に入っていない、DKIM の署名が自社のドメインでされていない、ことです。

SPF の include などの参照が10回を超えていないか、レコードが1つにまとまっているかも見ます。DMARC のレポートで、どの送信元が不合格かを確かめて直します。認証が合格しているのに迷惑メールになるなら、送る量や内容、受け取った側の設定も確認します。

深掘りされたら

  • DMARC のレポートはどう読みますか?

見られているポイントヘッダーでの確認・送信元の漏れ・SPF の上限・レポート