Googleは巨大なインフラをどうやってセキュアに保っているか。独自のセキュリティチップ利用やDoS対策、安全なソフトウェア開発など、全体像を解説したホワイトペーパーを公開

2017年1月16日

Googleのクラウドは間違いなく世界最大規模のコンピュータシステムです。膨大なハードウェアとソフトウェアから構成されるこの巨大なシステムを、同社はどうやってセキュアに保っているのか。そのことを解説したホワイトペーパー「Google Infrastructure Security Design Overview」が公開されました

fig

ホワイトペーパーには、Googleのデータセンターを構成するデバイスの1つ1つにまで独自のセキュリティチップを組み込んで正規のデバイスかどうかを相互に認証するという物理レベルのセキュリティから、何層のものロードバランサーからの情報を集約してDos攻撃を検知すると、その通信を破棄するといったDoS対策。

そしてマシンも従業員もサービスも包括するグローバルな名前空間など、きわめて広範かつ綿密なセキュリティ施策が説明されています。

クラウドがいかに高度なセキュリティで保たれているか分かると同時に、企業や組織のセキュリティ対策の参考にもなるでしょう。

ホワイトペーパーは長文の英文ですが、それほど複雑な内容ではないので時間さえあれば読みこなせると思います。ここでは主な項目の要点をまとめてみました。これだけでも緻密なセキュリティ対策がほどこされていることが分かるはずです。詳しくはぜひ原文をあたってみてください。

Google Infrastructure Security Design Overview

Security of Physical Premises(施設のセキュリティ)

データセンターの施設を守るため、バイオメトリクスによる認証、金属探知機、カメラ、車両進入防御壁、レーザー侵入探知機など、多層の設備を採用。

Hardware Design and Provenance(ハードウェアの設計と来歴)

サーバとネットワーク機器はGoogleの独自設計で、製造ベンダは綿密に調査し、部品もコンポーネントベンダからのセキュリティに関する情報を監査するなど注意深く選択。ハードウェアセキュリティの独自チップをサーバと周辺機器に組み込み、正規のハードウェアであることをハードウェアレベルで認証、承認。

Secure Boot Stack and Machine Identity(セキュアなブートスタックとマシンの身元確認)

BIOS、ブートローダ、カーネル、OSイメージなどに対して暗号化署名を用いて正しく起動しているかを確認。データセンター内の各サーバはそれぞれのIDを持ち、ハードウェアや起動したソフトウェアに関連付けられ、ローレベルの管理ツールなどで認証のAPIでの呼び出しに使われる。

Service Identity, Integrity, and Isolation(サービスのアイデンティティ、整合性、分離)

サービス間で通信を行う場合には、アプリケーションレイヤで暗号化された認証と承認を採用。

主要なセキュリティの仕組みとしては、ネットワークのセグメンテーションやファイアウォールを用いていない。

サービスのソースコードは中央のリポジトリに過去のバージョンも含めて保存され、監査可能。バイナリは決められたレビューを経てチェックインされ、テストされることを要求される。コードレビューは監査および作成者以外のエンジニアの承認が必要であり、あらゆるシステムのコードの変更はそのシステムオーナーの承認が必要である。

Inter-Service Access Management(サービス間のアクセスマネジメント)

サービスのオーナーは、インフラが提供するアクセス管理機能によって、そのサービスがどのサービスと通信可能かを設定できる。エンジニアがアクセスするサービスも、エンジニアのIDによってサービスのアクセス管理が可能。

マシン、サービス、従業員のID全体がグローバルな名前空間に包括されている。

インフラはこのIDに対して承認ワークフローやロギング、通知などの豊富な管理機能を備えている。

Encryption of Inter-Service Communication(サービス間通信の暗号化)

インフラはRPCの認証と承認に加えて、ネットワーク上のRPCデータに対して暗号化(cryptographic privacy)を提供。インフラのRPC機構にこれを組み込むことで、アプリケーションレイヤにおけるHTTP通信などでもこのセキュリティのメリットを得られる。これらにより、アプリケーションはセキュリティやネットワークのパスなどに依存することがなくなる。

Access Management of End User Data(ユーザーデータのアクセス管理)

ユーザーがログインし、それがインフラの中央ユーザーIDサービスによって検証されると、CookieやOAuthトークンなどのエンドユーザークレデンシャルをクライアントに発行する。クライアントがGoogleのサービスを利用する場合、このエンドユーザークレデンシャルの提示が必要となる。

サービスがエンドユーザークレデンシャルを受け取ると、中央ユーザーIDサービスによって検証され、正当なものであれば、RPC関連のリクエストに使える短命な「エンドユーザーパーミッションチケット」が発行される。

fig

Encryption at Rest(保存データの暗号化)

BigTableやSpannerなどほとんどのストレージサービスは、暗号化キーを用いてストレージのデータにアクセスする。

アプリケーションレイヤでの暗号化は、悪意のあるディスクのファームウェアなどによる脅威への対策となり得る。同時にGoogleでは、ハードディスクやSSDのレベルでの暗号化も利用している。

Deletion of Data(データの削除)

データの削除でもっとも多いのは「計画的消去」である。これにより、ユーザーの操作ミスあるいはバグやエラーなどによる意図しないデータの削除が行われた場合にもデータの復旧が可能となる。

Google Front End Service

サービスがインターネットで利用可能になるために、サービスが自身をインフラが提供するGoogle Front End(GFE)に登録できる。GFEはTLSコネクションが適切に終了することや、perfect forward secrecyといったセキュリティのベストプラクティスに沿った通信を実現する。

GFEはさらに、DoS攻撃からの防御も行う。

Denial of Service (DoS) Protection(DoS攻撃からの防御)

マルチティア、マルチレイヤにわたるDoS攻撃からの防御によって、GFEの背後で稼働しているサービスをDoSから守る。

バックボーンを通じて届く通信は、何層かのハードウェアおよびソフトウェアのロードバランサーを通過する。ロードバランサーは通信の情報をインフラ上で稼働する中央DoSサービスへ報告。中央DoSサービスがDoS攻撃の開始を検知すると、DoSの通信を破棄もしくは絞るようにロードバランサーを制御する。

GFEインスタンスもアプリケーションレイヤにおける情報を中央DoSサービスへ報告し、ここでもDoSが検知されればGFEインスタンスが通信を破棄するように制御される。

User Authentication(ユーザーの認証)

Dos攻撃からの防御に続いての防御は中央アイデンティティサービスによる。ユーザー名やパスワードを確認した上で、同一のデバイスや同一ロケーションからのログインかどうかなどの追加情報を基にしてユーザーからの脅威があるかどうかをインテリジェントに判断する。

Safe Software Development(安全なソフトウェアの開発)

中央コードリポジトリや関係者のレビューなどに加えて、開発者がXSSといったセキュリティ関連のバグを組み込まないよう、ライブラリを提供しており、またコードの静的解析ツール、Webセキュリティスキャナーなどを用意している。

最終チェックとしてマニュアルでのセキュリティレビューを行っている。これはWebセキュリティ、暗号化、OSセキュリティなどの専門家による、些細なリスクの判断から深刻な設計や実装レビューまで行われている。

さらに脆弱性を発見したものに対する脆弱性報奨金プログラムを行っており、これまでに数百万ドル(数億円)を支払った。

Keeping Employee Devices and Credentials Safe(従業員のデバイスとクレデンシャルの安全を保つ)

従業員を対象にした洗練されたフィッシングがこれまで行われてきており、フィッシング可能なOTP second factors(ワンタイムパスワード2要素認証)をU2F-compatible Security Keys(ユニバーサル2要素認証互換なセキュリティキー)に置き換えた。

従業員がインフラを操作するために用いるクライアントデバイスのモニタリングにも膨大な投資を行っている。これらクライアントデバイスのOSに最新のセキュリティパッチがあたっているかを確認し、インストール可能なアプリケーションを管理している。さらにインストールされたアプリ、ダウンロードされたファイル、ブラウザ拡張、ブラウジングされたWebページなどをスキャンするためのシステムも備えている。

Reducing Insider Risk(社内リスクの低減)

インフラにアクセス可能な従業員の行動はつねにモニタされ、同時に強く制限されている。またより安全な作業を実現するために、徹底的な自動化によって特権的なアクセスを可能な限り排除するようにしている。

Intrusion Detection(侵入検知)

インフラの多数のデバイスからのモニタリング情報やシグナルから、ルールおよびインテリジェントな方法で侵入インシデントの可能性があった場合に警告が行われる。調査およびインシデント対応チームが24時間365日、これに対応する。

以下、さらにGoogle Cloud Platformに関するセキュリティの体制が説明されています。詳しくはぜひ原文をあたってみてください

あわせて読みたい

クラウド セキュリティ 殿堂入り Google




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本