Instiq

Google Cloud Associate Google Workspace Administrator のナレッジマップ

Google Cloud Associate Google Workspace Administrator の主要概念 38 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(38)

  • 調査ツール(investigation tool)

    セキュリティインシデント(フィッシング拡散など)でログを横断的に検索し、該当メッセージの一括削除やデバイス対処などの一括アクションをとるツール。一括アクションは強力なため影響範囲を確認してから実行する。

    前提: ユーザーのライフサイクルと侵害対応

  • Google Drive(共有設定)

    Workspace のファイルストレージ。管理者は共有範囲(社内/外部・リンク共有)、共有を許可/制限、共有ドライブの利用などを OU やグループ単位で制御する。

    関連: 共有ドライブ

  • Gmail(管理)

    Workspace のメールサービス。管理者はルーティング/受信ルール、コンテンツ・添付ファイルの制限、配信状況の確認、メールヘッダー分析(なりすまし調査)などを設定・運用する。

    関連: Gmail のルーティング

  • DLP ルール(Workspace)

    Drive や Gmail で機微情報の共有/送信を検知し、警告またはブロックするルール。検出条件(定義済み/カスタム)とアクション(警告・ブロック・監査)を設定する。

    前提: Google Drive(共有設定)Gmail(管理)

  • パスキー(Google Workspace)

    パスワードを使わず、デバイスの生体認証(指紋/顔)や画面ロック PIN に紐づく暗号鍵ペアで本人確認するフィッシング耐性の高い認証方式。Google Workspace 管理者は組織部門(OU)単位でパスキーの利用を許可・必須化でき、2 段階認証プロセス(2SV)の一方式として設定する。

    前提: 組織単位(OU)

    関連: 2 段階認証プロセス(2SV)

  • 2 段階認証プロセス(2SV)

    パスワードに加えて二つ目の要素を求める認証強化。OU/グループ単位で強制でき、方式は SMS/プロンプト/最も強いセキュリティキー・パスキー(FIDO)まで幅がある。

    関連: パスキー(Google Workspace)

  • コンテキストアウェアアクセス

    デバイスの状態・場所/国・IP 範囲・企業デバイスかどうかなどの条件に応じてアクセスを許可/制限するゼロトラスト的な制御。認証強化(2SV/SSO)とは別レイヤーで組み合わせて使う。

  • ユーザーのライフサイクルと侵害対応

    ユーザーアカウントの作成・停止・削除と、侵害時の対応。停止 / パスワード再設定 / セッション失効で素早く封じ込め、一括アクションで多数を処理、アカウント復旧で誤操作に備える。

  • SAML SSO(シングルサインオン)

    組織/Enterprise のメンバーが IdP(Entra ID・Okta 等)で認証してから GitHub にアクセスする仕組み。認証を担い、退職者のアクセスを一括で止められる。アカウントの自動削除は SCIM の役割で、SAML 単独では行われない。

    前提: シングルサインオン(SSO)

  • 組織単位(OU)

    AWS Organizations 内でアカウントを階層的にグループ化する単位。OU 単位で SCP を適用し、環境(本番/開発)や部門ごとにガードレールを分けて統制する。

  • シングルサインオン(SSO)

    一度のサインインで複数のアプリにアクセスできる仕組み。

  • 監査ログとサインインログ

    ユーザーや管理者の操作を記録する監査ログと、認証イベントを記録するサインインログ。誰がいつ何をしたかを追跡し、調査やトラブルシューティングに使う。

  • データリージョン

    Workspace の保存データを特定の地理(例: 米国/欧州)に限定し、データ所在地の規制に対応する設定。内容ベースの DLP や相手ドメインベースの信頼ルールとは別軸。

    前提: 信頼ルール(trust rules)

  • Workspace のエディション

    Business(Starter/Standard/Plus)や Enterprise などの契約区分。利用できる高度なセキュリティ/コンプライアンス機能(DLP・Vault・コンテキストアウェアアクセス等)はエディションに依存する。

    前提: コンテキストアウェアアクセスGoogle Vault(保持ルールとホールド)

  • Gmail のルーティング

    特定条件に一致するメールを別の宛先やサーバーへ転送・振り分ける Gmail の設定。コンプライアンス目的のコンテンツ/添付制限と併用する。

    関連: Gmail(管理)

  • セキュリティダッシュボードとアラートセンター

    セキュリティダッシュボードは組織のセキュリティ状況(共有・スパム・認証)を俯瞰する。アラートセンターは不審ログインやフィッシングなどの通知を受け、調査ツールと連携して対応する。役割が異なり組み合わせて使う。

    前提: 調査ツール(investigation tool)

  • 共有ドライブ

    チームで共同所有する Drive の領域。個人のマイドライブと違い、メンバーが入れ替わってもファイルが組織に残る。

    関連: Google Drive(共有設定)

  • 信頼ルール(trust rules)

    どの外部組織(ドメイン)とのファイル共有を許可/制限するかを定め、外部共有を統制する仕組み。相手ドメインベースで、内容ベースの DLP とは軸が異なる。

  • Google Vault(保持ルールとホールド)

    データを一定期間保持し期限後に削除する保持ルールと、訴訟/調査のためにデータを保全するホールドを担う。ホールドは保持ルールの削除に優先する。保全済みデータは eDiscovery で検索・エクスポートする。

    関連: eDiscovery(電子証拠開示)

  • 送信ドメイン認証(SPF/DKIM/DMARC)

    送信ドメイン認証の 3 要素。SPF はそのドメインからの送信を許可する IP を列挙し、DKIM は電子署名でメール本文の改ざんの無さと送信元を証明し、DMARC は SPF/DKIM の検証結果に基づく処理方針(隔離/拒否)と結果通知先を宣言する。なりすまし・フィッシング対策として TXT レコードで設定し、Google Workspace でも受信側の迷惑メール判定に強く影響する。

  • Apps Script

    Google Workspace 向けの JavaScript ベースの自動化・拡張プラットフォーム。Gmail/Drive/Sheets などを横断するスクリプトやアドオンを作成できる。

    前提: Google Drive(共有設定)Gmail(管理)

  • HTTPS

    HTTPをTLSの上に載せて運ぶプロトコル。通常のHTTPと違い通信内容が暗号化され、途中経路での盗聴・改ざんを防げる。ブラウザは証明書を検証してサーバーの正当性を確認し、Webサイトの標準的な通信方式になっている。

    関連: TLS

  • TLS

    通信を暗号化し、証明書によってサーバー(要件次第ではクライアントも)を認証するプロトコル。ハンドシェイクで鍵交換と認証を行った後、対称鍵でデータを暗号化して送受信する。クラウドのロードバランサやCDNで終端し、証明書はマネージドサービスで発行・更新するのが一般的。

    前提: マネージドサービス(管理の境界)

    関連: HTTPS

  • Cloud Identity

    ユーザーとグループを管理し、外部 ID プロバイダーと SAML SSO や Directory Sync / GCDS で連携する Google のサービス。

    前提: SAML SSO(シングルサインオン)

  • アプリアクセス制御(API アクセス管理)

    Marketplace アプリやサードパーティの連携アプリが Workspace データへアクセスする可否を制御し、信頼するアプリだけに限定して未確認アプリをブロックする仕組み。サービスのオン/オフとは別レイヤー。

    関連: Marketplace アプリ / サードパーティアプリ管理

  • エンドポイント(デバイス)管理

    基本管理は画面ロック要求など最低限の保護、高度な管理はデバイス承認・細かいポリシー・リモートワイプまで行う。会社所有は強い管理、個人所有(BYOD)はアカウントワイプで業務データのみを保護する。

    関連: デバイス管理レベル(基本 / 高度)

  • BigQuery へのログエクスポート

    監査ログ/利用状況データを BigQuery に継続エクスポートし、SQL で横断分析・長期保管・カスタムレポート作成を行う。

    前提: 監査ログとサインインログ

  • デバイス管理レベル(基本 / 高度)

    エンドポイント管理の強度。基本管理=登録不要で最小限の制御。高度な管理=登録のうえ画面ロック・暗号化・ワイプ等の強い制御。会社所有/個人所有(BYOD)で使い分ける。

    関連: エンドポイント(デバイス)管理

  • Marketplace アプリ / サードパーティアプリ管理

    Google Workspace Marketplace のアプリや、OAuth で接続するサードパーティアプリへのアクセスを統制する。アプリ単位の許可/ブロック、API アクセス管理(アプリアクセス制御)、未構成アプリの信頼/制限設定で不正な連携を防ぐ。

    関連: アプリアクセス制御(API アクセス管理)

  • eDiscovery(電子証拠開示)

    訴訟や調査のために関連コンテンツを検索・保全(ホールド)・収集・書き出しする仕組み。

    関連: Google Vault(保持ルールとホールド)

  • 保管時の暗号化(at rest)

    ディスクやオブジェクトストレージ上に保存されているデータを暗号化すること。クラウドの多くのマネージドストレージ(ブロック/ファイル/オブジェクト/DB)はサービス側の鍵管理(KMSなど)と統合した暗号化オプションを持つ。盗難・不正アクセスからデータ本体を守る基本対策。

  • 転送時の暗号化(in transit)

    ネットワーク経路を通過中のデータを暗号化すること。多くの場合TLSで通信を保護する。保管時の暗号化と組み合わせて初めて、データのライフサイクル全体(保存中・移動中)を防御できるため、両方を満たすのがセキュリティの基本要件となる。

    前提: 保管時の暗号化(at rest)

  • セキュリティ センター(Workspace)

    Google Workspace 管理コンソールのセキュリティ分析ダッシュボード。セキュリティの健全性ページ・調査ツール・アラートで、リスクの可視化と是正を支援する。

    前提: 調査ツール(investigation tool)

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  • マネージドサービス(管理の境界)

    AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

  • ポート番号

    同じ IP アドレス上で動く複数のサービスを識別する 16 ビットの番号(例:HTTP は 80、HTTPS は 443、SSH は 22)。TCP・UDP のヘッダーに含まれ、ファイアウォールやセキュリティグループのルールは送信元/宛先ポートで通信を許可・拒否する。

    前提: HTTPS

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: JSON