最近ニュースで取り上げられているKADOKAWAのランサムウェア被害を見て、私も前職でランサムウェア被害に対応した経験があるため、色々と考えさせられています。
前職ではオンプレミスのネットワークエンジニアとして働いていましたが、現在はクラウドエンジニアとして、主にGoogle Cloudの設計・構築・運用を行っています。
今回のブログでは、KADOKAWAのランサムウェア被害を受けて、私が考えたGoogle Cloudのセキュアな設計について皆さんに共有しようと思います。
今回は、Identity ProviderのCloud Identity（Google Workspace）とGoogle Cloud Platformの2つの軸で説明します。Google Cloud Platformは旧称ですが、Cloud Identity（Google Workspace）もGoogle Cloudに含まれるため、今回は区別するためにGoogle Cloud Platformという名称を使用します。
運用や各サービスの設計については、別のブログで書こうと思います。
今後、Google Cloudの設計を行う方や、既に使用されている方のお役に立てれば幸いです。
是非、最後までご覧いただけると嬉しいです。
Cloud Identity(Google Workspace)の設計
Cloud Identityのセキュアな設計に関しては、以下４点を提案します。
- 強力なパスワード設定
- 多要素認証の導入
- 共有アカウントの使用禁止
- 不審なログイン等を検知
一つずつ詳しく説明します。
1. 強力なパスワード設定
まずは、Google アカウントに対する強力なパスワード設定です。私が推奨するパスワード設定は、以下3点です。
- 最低15文字以上の長さにする
- 大文字、小文字、数字、記号の4種類の文字を使用する
- 他のサービスと同じパスワードを使用しない
パスワードの桁数は、長ければ長いほど解読されにくくなります。Googleアカウントの場合、最大100文字までのパスワードを設定することができます。パスワードは無理に分かりにくくする必要はなく、「Watashiha#Hajimenoitwo2022Nennkarahajimeteimasu（私は、はじめのiTを2022年から始めています）」のように普通の文章で構いません。それよりも、長さと複数の文字種を使うことが重要です。ただし、アカウント名やキーボードの並び順を使った一般的なパスワードは避けるべきです。
以前、YouTubeでパスワードクラッカーをプログラミングで作成している方の動画を見たことがありますが、パスワードを解読する際には、文字種を順番に使って該当するパスワードを探すため、長いパスワードほど解読に時間がかかります。
私は、パスワードは長ければ長いほど良いと考えています。
2. 多要素認証の導入
次は、Google アカウントにログインする際、多要素認証を導入することです。多要素認証を導入することで、アカウントの不正ログインをより困難にすることができます。
私が推奨する多要素認証の方法は、以下の2つです。
- Titan セキュリティキー
- Google 認証システムアプリ
Titanセキュリティキーは、Googleが独自に設計したセキュリティチップを搭載した物理的なキーです。使用方法は、Googleアカウントに対してTitanセキュリティキーを登録し、二段階認証時にTitanセキュリティキーをパソコンに接続します。
Google 認証システムアプリは、ワンタイムパスワードを発行し、それを使用してログインします。スマートフォンが普及した現代では、誰でもインストールでき、セキュリティを向上させることができます。私もこの方法を採用しています。
その他に多要素認証で使用できるものとして、以下の2つがありますが、推奨しません。
- テキストメッセージや音声電話で受け取った確認コード
- バックアップコード
テキストメッセージや音声電話で受け取った確認コードを使用しないほうがよい理由は、送信されたSMSをハイジャックすることができるソフトウェアやハードウェアがあるためです。また、バックアップコードは、一度発行すると再発行ができなくなる欠点があるので、紛失するとアカウントにアクセスできなくなります。
以上のことから、多要素認証で使用する方法は、「Titan セキュリティー」または「Google認証システムアプリ」を推奨します。
3. 共有アカウントは使用禁止
共有アカウントとは、１つのアカウントを複数人で使用するアカウントです。共有アカウントを使用すると、実際に誰が使用していたか特定することが困難になります。リモートワークなどで異なるIPアドレス（場所）を使用している場合は、まだ特定することが可能ですが、職場やプロキシサーバーサービス経由でGoogle Cloudにアクセスしている場合、誰がそのアカウントを使用していたか特定することが難しくなります。
共有アカウントは、例えばメールエイリアスのように、複数人に一斉にメールを送信する際には非常に便利です。しかし、Google Cloudで使用する場合、責任の所在が不明瞭になるため、使用は禁止とします。
4. 不審なログイン等を検知
Cloud Identity（Google Workspace）の管理コンソールにおける「ルール」を活用することで、アカウントの不審なログイン等を検知することができます。
実際のルールが以下になります。
このルールには、「不審なログイン」や「プログラムによる不審なログイン」が含まれ、Googleが独自に調査した実績を基に、脅威を検出しメールを送信することができます。
ただし、このメール通知機能は、Cloud Identity（Google Workspace）でGmail（メール機能）を使用している場合にのみ利用可能です。使用していない場合は、メールにてアラート通知を行うことができません。その場合、Cloud Identity（Google Workspace）のログをGoogle Cloud Platformと共有することで、Google Cloud Platform側でログベースのアラートを作成することができます。
Cloud Identity(Google Workspace)のログをGoogle Cloud Platformに共有する場合は、「アカウント設定」→「法とコンプライアンス」→「共有オプション」を「有効」にします。
この設定により、Cloud Identity（Google Workspace）のログが Google Cloud Platform に共有され、Cloud Monitoring でログベースのアラートを作成することで、ログインに関するアラートを作成できます。
具体的な方法については、別のブログで詳しく設定方法を説明しようと思います。
以上4点が、私が提案するCloud Identity(Google Workspace)のセキュアな設計になります。
Google Cloud Platformの設計
Google Cloud Platformのセキュアな設計に関して、私が提案する方法は以下の７点です。
- デバイス登録ポリシーを導入する
- サービスアカウントやユーザーアカウント（又はGoogle グループ）には最小限の権限を付与する
- IAMにドメイン制限を設定する
- Cloud Shellの使用を制限する
- Google CloudコンソールおよびSDKのセッション管理を短くする
- サービスアカウントキーの発行を最小限にし、極力 Workload Identity 連携を利用する
- Security Command Centerを使用する
一つずつ詳しく説明します。
1. デバイス登録ポリシーを導入する
まずは、Google Cloudを利用するデバイスを厳格に管理するために、デバイス登録ポリシーを導入することです。Google Cloudには、BeyondCorp Enterpriseというサービスがあります。
BeyondCorp Enterpriseは、従来のネットワーク境界に依存しないゼロトラストセキュリティモデルに基づいた、企業向けの高度なセキュリティソリューションです。Google自身が培ってきたゼロトラストモデルを基盤に構築されており、ネットワークの内外を問わず、すべてのアクセスリクエストを厳格に認証・承認し、暗号化された通信で安全に検証します。従来のVPNに頼るアプローチとは異なり、どこからでも安全に業務を行える環境を実現します。
BeyondCorp Enterpriseでは、デバイス情報を登録し、登録されていないデバイスからのアクセスを確実にブロックします。さらに、Googleアカウント、IPアドレス、地域など、さまざまな条件に基づいてアクセスをきめ細かく制限することが可能です。これにより、不正アクセスを効果的に防止し、Google Cloudのセキュリティを飛躍的に向上させることができます
2. サービスアカウントやユーザーアカウント（又はGoogle グループ）には、最小限の権限を付与する
アカウント権限が大きいほど、もし乗っ取られた場合、攻撃者はその権限を使ってGoogle Cloudのリソースを不正に変更し、甚大な被害をもたらす可能性があります。ハッカーがランサムウェアを使って企業のデータを暗号化する際、この強い権限を持つアカウントを利用して暗号化を行います。
企業のサーバーがハッキングされる要因の一つとして、内部情報漏洩も挙げられます。 従業員が意図的・非故意に関わらず情報を漏洩してしまうケースは少なくありません。そのため、サービスアカウントやユーザーアカウント（Googleグループ）に対しても、過剰な権限を付与することは避け、必要な権限のみを付与することが重要です。
以上の理由から、サービスアカウントやユーザーアカウント（Googleグループ）には、最小権限の原則に基づいて、必要な権限のみを付与する必要があります。
最小権限の原則とは、ユーザーがタスクを遂行するために本当に必要な権限のみを付与するという考え方です。 この原則を徹底することで、情報漏洩や不正アクセスのリスクを大幅に低減することができます。
3. IAMにドメイン制限を設定する
IAMにドメイン制限を設定することで、組織のセキュリティを飛躍的に強化することができます。ドメイン制限に関しては、以下のブログで説明していますので、そちらもご参照ください。
Cloud Identityを使用することで、Google Cloud にログインしたユーザーのログイン日時を詳細に確認することができます。以下が、実際のCloud Identityの画面です。「最終ログイン」から、最後にいつログインしたかを確認することができます。
しかし、自ドメイン外のアカウントではログイン履歴を確認することができず、退職者などのアカウントが削除されずに残っている場合、乗っ取られて不正アクセスされるリスクがあります。
以上の理由から、ドメイン制限を設定することで、自ドメイン外のアカウントに対してIAM権限を付与できなくなり、不正アクセスのリスクを大幅に低減することができます。
4. Cloud Shellの使用は制限する
Google Cloud Platform のCloud Shellは、利便性の高い管理用シェル環境ですが、その一方でいくつかのセキュリティリスクも存在します。
主なリスクは以下の3点です。
- 監査ログの欠如による不正アクセスの追跡困難
Cloud Shellで行われた操作は監査ログに記録されないため、アカウント乗っ取りなどの不正アクセスが発生した場合、その痕跡を追跡することが困難になります。
- 外部コード実行によるマルウェア感染リスク
Cloud Shellを通じて外部のコードやスクリプトを実行する場合、それらにマルウェアが含まれているリスクがあります。感染したマルウェアがクラウド環境に拡散し、情報漏洩やシステム障害などの被害を引き起こす可能性があります。
- プロキシサーバーの迂回による情報漏洩リスク
プロキシサーバーを経由してGoogle Cloud コンソールにアクセスする場合、Cloud Shellを使用するとプロキシサーバーを迂回して直接インターネットにアクセスできてしまいます。これは、情報漏洩や不正アクセスのリスクを高める可能性があります。
以上の理由から、Cloud Shellの使用は極力制限することが望ましいです。
ちなみに、Cloud Shellの使用制限は、Cloud Identity(Google Workspace)の管理コンソールから行うことができます。
5. Google Cloud コンソールおよび SDK のセッション管理は短くする
Google Cloud コンソール及び SDK のセッション管理時間を短縮することで、セキュリティを大幅に向上させることができます。
セッション管理時間を長く設定することによる主なリスクは以下の3点です。
- セッションハイジャック攻撃による不正アクセス
セッションが長く保持されると、攻撃者がセッションIDを盗んだり、フィッシング攻撃でログイン情報を詐取したりするなど、セッションハイジャック攻撃のリスクが高まります。攻撃者は乗っ取ったセッションを使って、リソースの不正操作や情報漏洩などを引き起こす可能性があります。
- 離席中の不正アクセス
ユーザーが離席している間に、そのセッションがアクティブなまま放置されてしまうと、第三者がその端末から不正にアクセスできる可能性があります。特に、パスワードを保存した状態で端末を放置した場合、被害が甚大化します。
- セッション乗っ取りによる被害拡大
セッションが長いほど、乗っ取られた場合の被害が拡大する可能性があります。攻撃者は、長い時間をかけてリソースを操作したり、情報を窃取したりするなど、より巧妙な攻撃を行うことができます。
以上の理由から、セッション管理時間はできるだけ短く設定することが重要です。
ただし、セッション管理時間を短縮すると、ユーザーが頻繁にログインし直す必要があり、利便性が低下するというデメリットもあります。
そこで、私はセッション管理時間の最小値として1時間を提案します。 1時間であれば、ユーザーの利便性を大きく損なうことなく、セキュリティリスクを大幅に低減することができます。
なお、セッション管理時間は、組織のセキュリティポリシーや業務内容に合わせて調整する必要があります。
セッション管理の設定も、Cloud Identity(Google Workspace)の管理コンソールから行うことができます。
6. サービスアカウントキーの発行は最小限にし、極力 Workload Indeitity 連携を利用する
次が、サービスアカウントキーの発行は最小限にし、極力 Workload Identity 連携を利用するです。
サービスアカウントキーとは、サービスアカウントに成り代わって操作を行うための認証キーです。キーが漏洩した場合、不正者がGoogle Cloud リソースにアクセスし、データの窃取や改ざん、システムの破壊などを引き起こす可能性があります。特に、サービスアカウントキーは非常に強力な権限を持つため、漏洩時のリスクは極めて高くなります。
2024年6月16日以降、Google Cloudは、GitHub やGitLab の公開リポジトリなどに登録されているサービスアカウントキーを無効化する対応を実施します。
外部のクラウドサービス(AWSやAzure など)や SaaS と連携する場合は、サービスアカウントキーの代わりに、Workload Identity 連携を利用することを強く推奨します。Workload Identity 連携は、サービスアカウントキーを発行することなく、安全に連携を実現する機能です。
Workload Identityについては、以前のブログで説明していますので、そちらをご参照ください。
サービスアカウントを外部のクラウドサービスや SaaS と連携する場合は、キーの発行ではなく、Workload Identity 連携を使用することで、セキュリティを大幅に向上させることができます。
7. Security Command Centerを使用する
最後にご提案するのが、Security Command Centerを使用するです。
Security Command Centerは、Google Cloud Platform上のすべてのリソースを包括的に可視化し、脅威の検知、分析、対応を支援するセキュリティ管理サービスです。
Security Command Centerには、脆弱性管理と脅威検知およびインシデントレスポンスという機能があります。
脆弱性管理は、ソフトウェアの脆弱性、構成ミス、誤ったアクセス権限設定などを自動的にスキャンし、検出します。
脅威検知とインシデントレスポンスは、脅威インジケーターに基づいて、マルウェア感染、不正アクセス、データ漏洩などの脅威を検知します。
Security Command Centerには、StandardとPremiumの2つのプランがあります。
Standardプランは無料で利用可能ですが、脆弱性管理や脅威検知とインシデントレスポンスといった、重要なセキュリティ機能は含まれていません。
Premiumプランは、これらの機能に加え、高度なセキュリティ分析や自動化機能などを利用することができます。従量課金制のため、Google Cloudの利用量に応じて料金が発生します。 利用状況に合わせて、StandardプランとPremiumプランを適切に使い分けることをおすすめします。
重要なサービスをデプロイしているプロジェクトなど、セキュリティ対策を強化したいプロジェクトだけ、Premiumプランを導入することができます。
以上7点が、私が提案するGoogle Cloud Platformのセキュア設計になります。今回は、設計に焦点を当てて説明しました。今後、運用と各サービスのセキュアな設計については、別のブログで説明します。
まとめ
今回は、下記２点について説明しました。
- Cloud Identity(Google Workspace)の設計
- Google Cloud Platformの設計
ランサムウェアの被害からGoogle Cloudのリソースを守るため、私が考えるCloud Identity(Google Workspace)とGoogle Cloud Platformの2つのセキュアな設計について説明しました。これからも、ランサムウェアの被害を防ぐために、自分ができることを精一杯やっていきたいと思います。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
