Google Cloud

Google Cloud データベースセキュリティのベストプラクティス

2018年6月12日

Google Cloud Japan Team

情報を黄金にたとえるなら、データベースは宝箱です。ウェブアプリケーションは最も重要なデータをデータベースに格納していますし、データの盗難や消失に見舞われたサイトの多くは消えてなくなります。そこでこの投稿では、Google Cloud Platform（GCP）にホスティングされたデータベースの保護に役立つ一連のベストプラクティスを紹介します。

データベースのセキュリティは最初のレコードが格納される前から始まっています。ホスティング環境を設計するときは、セキュリティへの影響を考慮しなければなりません。ファイアウォールルールからロギングまで、データベースの内外で考えなければならないことがたくさんあります。

最初に考慮すべきこと

データベースのセキュリティに関係する最も根本的な事柄の 1 つは、独自データベースサーバーをデプロイするか、それとも Google のマネージドストレージサービスを利用するかの選択です。どちらにするかは、既存のアーキテクチャ、スタッフのスキル、専門的な機能に関するポリシーとニーズに大きく左右されます。

本稿は特定の GCP サービスを売り込むためのものではありませんが、独自データベースをどうしてもデプロイしなければならない理由がなければ、マネージドサービスを使うことをお勧めします。

Google のマネージドデータベースサービスは、Google のような大規模環境に耐えられるように設計されており、Google のセキュリティモデルが持つあらゆる利点を備えています。PCI、SOX、HIPAA、GDPR などの規則に準拠することを目指す企業にとって、共有責任モデルによって自社の要件が大幅に減ることには大きな意味があるでしょう。これらの規則が適用されない場合でも、ベストプラクティスの標準として PCI SAQ A（PCI DSS 自己問診タイプ A）に従うことをお勧めします。

アクセス制御

まず、データベースへのアクセス自体をできる限り制限すべきです。自己ホスト型のデータベースでは、許可されたホストだけに情報のやり取りを認める VPC（Virtual Private Cloud）ファイアウォールルールを設定するようにしましょう。明確な必要性のないポートとエンドポイントはブロックしてください。

可能であれば、ファイアウォールに対する変更のログを収集し、予期しない変更にはアラートが送信されるようにしましょう。GCP のファイアウォールを変更すると、アラートの送信が自動的に行われます。Forseti Security などのツールは、Google のマネージドサービスと、Google Compute Engine インスタンス上のカスタムデータベースの両方で、セキュリティ設定を監視、管理できます。

データベースの起動にあたっては、運用環境についても考慮しなければなりません。サービスアカウントは、自動ローテーションされる鍵を使って Google データベースに対する権限付与を簡略化します。GCP 内の自己ホストデータベースでも、Cloud KMS（Key Management Service）を使えばローテーションを管理できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image4x1qc.max-700x700.max-700x700.png

データのセキュリティ

スキーマを実装するときは、データ保持のポリシーを常に念頭に置いておくようにしましょう。使っていない機密データは負債のようなものであり、アーカイブするか削除すべきです。

多くの法的規則では、そのようなデータを識別するためのガイダンス（HIPAA、PCI、GDPR、SOX）を提供しています。いずれアプリケーションは破られ、データベースの情報は流出するという悲観的セキュリティモデルで運用すると効果的かもしれません。そうすれば、データ保持や保存時暗号化などに関して決定を下さなければならないときに、考え方を明確にしやすくなります。

最悪の事態が発生してデータベースの情報が漏洩したときのために、出力トラフィックのスパイクといった予想外の挙動に応じてアラートが送られるようにすべきです。また、“カナリア” データと呼ばれる、通常の状況ではアプリケーションから決して見えないように作られた特別な情報も役に立つでしょう。カナリアアカウントによるログインやカナリア値のネットワーク通過を検出できるようにアプリケーションを設計するのです。たとえば、カナリアを見つけるとアラートを送り、漏洩防止のための緊急措置を取るようにアプリケーションを設計します。

カナリアデータは小売店の盗難防止タグと似たところがあります。盗難防止タグには既知の検出方法があり、製品の内部に隠すことができます。セキュリティ意識の高い小売業者は、店舗の出口にタグのセンサーを設置することで、在庫の不正な流出を検出しようとします。

もちろん、災害復旧計画の策定とテストも必要です。データベースのコピーを作るようにすれば、ある種の障害の影響を受けなくなりますが、データの書き換えや削除には対応できません。優れた災害復旧計画があれば、データ消失、ハードウェア障害、ネットワーク障害など、予想されるあらゆる災害が実際に発生したときに正しく対処できます。そして、いつもと同じように、信頼性の高い災害復旧のためにバックアップシステムを定期的にテスト、モニタリングしておきましょう。

構成、設定

データベースをデフォルトログイン付きでデプロイしたときは、最優先でそのアカウントを変更、または無効化すべきです。また、すべてのデータベースアカウントがパスワードで保護されているとしても、長くて複雑なパスワードが使われるようにしなければなりません。単純なパスワードや空パスワードが決して使用されないようにしてください。Cloud KMS を使用できる場合は、まずそれを使うようにしましょう。さらに、認証情報のローテーション計画を立て、予定外の鍵変更を実施するときの基準を定義しておくようにしてください。

どの認証方式を使用するかに関係なく、読み出し用、書き込み用、管理者用に別々の認証情報を用意する必要があります。アプリケーションが読み書きの両方の処理を実行する場合でも、認証情報を分けておけば、コードの不良や不正アクセスによる被害を小さく抑えることができます。

データベースへのアクセスを必要とするすべてのユーザーに対し、その個人専用の認証情報を与えましょう。個々のアプリケーションには、サービスで必要とされるだけの許可を与えたサービスアカウントを作るようにします。GCP においてユーザーの権限を管理するときは、Cloud IAM が強力なツールになります。

汎用管理者アカウントは、ユーザーを識別できなくなるおそれがあり、避けるべきです。ユーザーの権限についても、職務遂行に最低限必要な範囲に制限します。たとえば、臨時の報告書を作るユーザーにスキーマ変更を認めてはなりません。また、ユーザーが知る必要のある部分だけにアクセスを制限し、SQL インジェクションに対する脆弱性を軽減するため、ビューやストアドプロシージャ、きめ細かいアクセス許可を適用することを検討してください。

ロギングは、あらゆるアプリケーションにとって重要です。データベースはすべてのキーイベント、特にログイン試行や管理者機能のログを生成すべきです。これらのログは、データベースとは離れたところにホスティングされた書き換え不能なロギングサービスで集約します。Stackdriver などのサービスを使っているかどうかにかかわらず、ログの認証情報と読み出しアクセスは、データベースの認証情報から完全に切り離すようにしましょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image3gd3f.max-700x700.max-700x700.png

可能であれば、総当たり的なログイン試行を検出してブロックするモニターやプロキシを実装すべきです。Stackdriver を使っている場合は、Cloud Functions ウェブフックにアラートポリシーをセットアップできます。Cloud Functions ウェブフックは、最近行われたログイン試行を監視して、不正利用の可能性があるものをブロックするためのファイアウォールルールを作成します。

データベースは、ルートや管理者ではなく、アプリケーションごとのユーザーアカウントで操作するようにします。すべてのホストファイルは、不正な実行や変更を防ぐため、適切なファイル所有権と操作許可を設定して保護します。POSIX 準拠 OS には操作許可を設定する chown および chmod コマンドがあり、Windows サーバーにも複数のツールが用意されています。Ubuntu の AppArmor などのツールは、さらにその先を行き、アプリケーションが使えるリソースを一部だけに制限します。

アプリケーションで考慮すべきこと

データベースに対して常に暗号化接続を使うことは、アプリケーション設計時の重要なベストプラクティスです。こうすれば、ネットワークスニッフィングによってデータや認証情報が漏れる可能性を排除できます。Cloud SQL のお客様は、Google の暗号化 SQL プロキシを使えばこれを実現できます。また、一部の暗号化方式は、アプリケーションがデータベースホストを認証することで、なりすましや中間者攻撃の脅威を軽減します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image2yjob.max-700x700.max-700x700.png

アプリケーションが特に機密性の高い情報を扱っている場合は、そもそもそのデータを保持する必要が本当にあるかどうかを確認しましょう。場合によっては、その種のデータの処理が法的な規則に委ねられ、判断結果が知らされることもあります。

しかし、そのような場合でも、データのセキュリティを確保するために追加的な対策を講じるべきです。一部のデータについては、自動的な保存時暗号化に加えてアプリケーションレベルでも暗号化しましょう。将来同じデータが示されるかどうかだけがわかればよいなら、データをハッシュ化する方法もあります。機械学習モデルのトレーニング向けにデータを使用する場合は、こちらのソリューションガイドをご一読ください。

アプリケーションのセキュリティはデータベースのセキュリティを強化するのに役立ちますが、データベースセキュリティの代わりに使ってはなりません。格納するデータかクエリのパラメータかにかかわらず、データベースに送られるあらゆる入力にはサニタイズなどの防衛手段が必要です。

また、すべてのアプリケーションコードには相互レビューを義務づけましょう。SQL インジェクションや XSS（クロスサイトスクリプティング）などの一般的な脆弱性に対するセキュリティスキャンは自動化し、頻繁に実行すべきです。

データベースへのアクセス権を持つ社員のコンピュータは、組織的なセキュリティポリシーの適用対象とすべきです。セキュリティの歴史に名を残す事件や事故のいくつかは、マルウェア、アップデートの不徹底、ポータブルストレージデバイスの不適切な使用などによるものでした。1 台のワークステーションが感染したら、それと接触したあらゆるシステムの感染を疑う必要があります。これにはプリンタやコピー機なども含まれます。

どのような状況のもとでも、サニタイズされていないデータを開発環境やテスト環境で使うことを認めてはなりません。このポリシーは、データベースのセキュリティを向上させるだけでなく、非本番環境から誤って顧客にメールを送ったり、アカウントに料金を発生させたり、状態を変更したりといった問題を引き起こす可能性をほぼ排除します。

自己ホストデータベースで問題になること

マネージドデータベースをご利用の場合は Google の共有責任モデルによって一部の懸念事項からは解放されますが、お客様自身がホスティングしているデータベースには同等の包括的なサービスは提供されません。こうした自己ホストデータベースの場合、あらゆる攻撃からの保護の責任をデータベース管理者が負わなければなりません。

独自データベースは、他の重要なアプリケーションの実行が認められていない専用ホストで実行しましょう。データベースは、ウェブホストなどからアクセスできるサービスと同じ論理ホストを共有してはなりません。それが不可能なら、そのサービスとデータベースは、必要最小限のホストが共有し、アクセスが可能な制限されたネットワークに置くようにしてください。論理ホストとは、アプリケーション自体が実行される最も下のレベルのコンピュータまたは仮想コンピュータのことです。GCP ではコンテナや仮想マシンインスタンス、オンプレミスでは物理サーバー、VM、コンテナなどが該当します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1dhu0.max-700x700.max-700x700.png

独自データベースを実行するユースケースとしてよく見られるのが、ハイブリッドクラウド内でのレプリケーションです。ハイブリッドクラウドデータベースは、たとえば、マスター、1 つ以上のクラウドのレプリカ、1 つのオンプレミスのレプリカから構成されます。その場合、データベースを社内 LAN や、利用者が多いその他のネットワークに接続してはなりません。同様に、オンプレミスハードウェアは、盗難や破壊の被害を受けないように、物理的にセキュアにしなければなりません。適切な物理的セキュリティを確保するには、物理的なアクセスの管理と自動ロギング、リモートからのビデオモニタリングなどが必要です。

自己ホストデータベースでは、アップデートが確認に行われたことの確認を定期的に実施する必要があります。ソフトウェアのアップデートポリシーを策定し、古くなったパッケージについてのアラートを送るようにしましょう。すべてのインスタンスを一括して簡単に操作できるほか、パッケージのバージョンを監視してアップグレードし、新しいインスタンスの構成および設定が可能なシステム管理ツール（Ubuntu、Red Hat）や設定管理ツールの使用を検討してください。設定ファイルや実行可能ファイルが格納されたディレクトリなど、ファイルシステム内の重要な部分についても、予定外の変更について監視する必要があります。

いくつかの規則は IDS（侵入検知システム）の利用を推奨しています。IDS の基本機能は、システムへの不正アクセスを監視し、それに対処することです。IDS には個別のサーバーで実行されるものと専用ゲートウェイホストで実行されるものがあり、市場にはさまざまな製品が出回っています。IDS の選定にあたっては、組織やアプリケーションに固有の要素の影響を受けることがあります。IDS は上述したカナリアデータのモニターとしても機能します。

どのデータベースにも、サービスをハードニングするうえで調整しなければならない設定項目があります。データベースソフトウェア固有のハードニングに関するアドバイスを得るには、まずはデータベースメーカーが提供しているドキュメントを読むことから始めてください。なお、よく使われているデータベースのハードニングガイドへのリンクを、後述の「参考文献」にまとめています。

土台となる OS もできる限りハードニングすべきであり、データベース機能にとって必要不可欠なもの以外のアプリケーションはすべて無効にすべきです。データベースをサンドボックス化またはコンテナ化すると、さらにしっかりと隔離できます。OS プラットフォーム固有のハードニングに関するアドバイスについては、OS のプロバイダーが作成したドキュメントを参照してください。後述の「参考文献」には、Google Compete Engine で利用できる一般的な OS のハードニングガイドへのリンクがまとめられています。

組織としてのセキュリティ

セキュリティの徹底をスタッフに求めるためのポリシーは、IT セキュリティにおいて重要でありながら見過ごされがちな部分です。これは非常に深く、陰影に富んだテーマですが、ここではデータベースのセキュリティ確保に役立つ一般的な事柄に絞って説明します。

機密データにアクセスするスタッフについては、全員犯罪歴のチェックを検討すべきです。異動後や退職後は直ちにユーザーアカウントを削除またはロックするというポリシーを厳格に遂行しましょう。アカウントのパスワードポリシーは NIST 発行の 2017 Digital Identity Guidelines（電子的認証に関するガイドライン）に従うようにしてください。また、ソーシャルエンジニアリングによるペネトレーションテストや、スタッフの不注意による攻撃の機会を減らすための訓練を実施することを検討しましょう。