2022-06-13

2022-06-13 Google Cloud Professional Cloud Security Engineer 模擬試験の解説

日々の学習記録

Google Cloud Professional Cloud Security Engineer の模擬試験を解いた。その後、その解説を確認し、掘り下げを行った。

その内容について、以下にまとめていく。

サービスアカウントの鍵の管理

問題

あるクラウド開発チームが、ローカル開発環境内でサービスアカウントを幅広く使用する必要があります。このチームに、そうしたサービスアカウント用の鍵を提供する必要があります。Google が推奨する方法に沿って対応する場合、何をすべきですか？

回答

毎日の鍵のローテーションプロセスを導入し、デベロッパーには、毎日新しい鍵をダウンロードできる Cloud Storage バケットを提供する。

解説

すべてのデベロッパーを含む Google グループを作成し、そのグループに、サービスアカウント管理者の IAM ロールを割り当て、デベロッパーには、各自で鍵を生成、ダウンロードしてもらう。

上記回答ではないかと思ったが、開発者にサービスアカウントの鍵の生成を委任することは情報漏洩の可能性があるため不適切。一元管理を行うことが望ましい。

Google Cloud Storage に鍵を定期生成し、その鍵へのアクセス権限を付与することによって開発者に鍵を提供することが望ましい。

サービスアカウントとは

仮想マシン上のワークロードや、オンプレのワークステーション及びデータセンタ上のワークロードから、 Google APIs にアクセスするためのもの。

「人間のライフサイクルには束縛されない」ワークロードであり、そのようなアカウントに付与される。人間のライフサイクルに束縛されるユーザアカウントと対照的である。

サービスアカウントをターゲットとしてユーザの権限を設定すると、ユーザはそのサービスアカウントを管理することができる。

2022-06-13

2022-06-13 DNSSEC について調べる

dev 日々の学習記録

顧客からの問い合わせで DNSSEC に関するものがあった (DNSSEC のレコードの監視)。

DNSSEC について全く知らなかったので、少し調査をすることにした。

概要

Domain Name System SECurity extensions (DNSSEC)。

DNS キャッシュポイズニングに代表される、 DNS を利用した攻撃を防止するために設計された。

DNSSEC を利用すると、悪意のあるサーバによる DNS データの偽装または操作をクライアントが受け入れないようにすることができる。

DNS キャッシュポイズニング

DNS キャッシュサーバが権威サーバに名前解決をした際のレスポンスを、攻撃者のサーバによって偽装されること。

キャッシュサーバに誤ったホスト名 / IPアドレスの対応が一定期間残るため、そのキャッシュサーバを利用するクライアントにおいて被害が発生する。

DNS キャッシュサーバ等クライアントと権威サーバ等サーバの間でのやり取りにおいてはメッセージに 16bit の ID が付与され、これの一致の確認が簡単な認証の役割を果たすが、 16bit 分(=約30000通り) しかパターンがないため、総当たりなどによって突破される危険性がある。

対策として DNSSEC が有効である。他に、この ID の bit 数を増やすという方法もある。

DNSSEC の構成

DNSSEC では、電子証明の仕組みを用いて構成サーバのホスト検証、改ざん検知を行う。

ゾーン作成者が秘密鍵と公開鍵を作成、 DNSKEY レコードという名称のレコードによって公開する。また、その秘密鍵を用いてゾーン内リソースのレコードについて電子署名を作成する。

DNS 情報を問い合わせたクライアントは問い合わせたレコード情報、DNSKEY レコードとして公開鍵情報、 PRSIG レコードとして電子署名情報を受け取り、受け取った公開鍵によって電子署名を復号することでレコードを検証する。

電子署名

電子署名は、コンテンツのハッシュを秘密鍵によって暗号化したものである。

検証する受け手はこれを公開鍵によって復号してコンテンツのハッシュを取得する。

コンテンツに同様のハッシュ関数を適用してハッシュを取得し、手元で生成したこれと復号によって得られたハッシュを比較する。

上位権威サーバによる信頼

DS レコードという、公開鍵のハッシュ値が公開されている。

この公開鍵のハッシュ情報に対し、上位の DNS サーバの秘密鍵を用いて署名し、上位の DNS サーバにおいて公開することで、クライアントは受けとった公開鍵を検証できるようになる。

手順としては、クライアントが受け取った公開鍵の署名を確認、その署名を上位の DNS サーバの公開鍵と比較。

一致していれば、その公開鍵は上位の DNS サーバによって認証されており、クライアントはその公開鍵が信頼に値すると判断することができる。

これによって証明書チェーンのように階層構造を構成し、上位 TLD の公開鍵をインストール、信頼するのみで配下の DNS サーバの公開鍵を連鎖的に検証、信頼できるようになる。

Ref

2022-06-09

2022-06-09 シングルサインオンについて

日々の学習記録

Google Certified Professional Cloud Security Engineer の学習をする過程で、シングルサインオンについて学んだ。

以下のページ。

Enable SSO for cloud apps | Cloud Identity | Google Cloud

IdP

Id Provider のこと。認証情報を一元管理する。

GCP であれば、 Cloud Identity が該当する。

IdP とアプリケーション間の連携は、主に以下の二つの手法によって行われる。

Security Assertion Markup Language 2.0 (SAML)
Open Id Connect (OIDC)

SAML は広く普及している規格で、対応しているサードパーティのアプリケーションも多い。

OIDC は比較的新しい規格で、軽量、アクセス管理が容易である等の利点がある。ただし、 SAML ほどまだ普及していない。

2022-06-09

2022-06-09 SNI とは？

dev 日々の学習記録

Transport Layer Security (TLS) の拡張仕様。RFC 6066として定義されている。

挙動

TLS による通信を行う際、クライアントはサーバに電子証明書の要求を行う。

この証明書に記載されたホスト名とリクエストしている FQDN を照らし合わせ、一致しているかをクライアント側で認証する。

TLS の拡張である SNI を利用する場合、TLS のネゴシエーションの初期の段階において、リクエストしているバーチャルホストの名称がクライアントからサーバに通知される。

これは、 ClientHello message に付加される情報という形で実現される。

ClientHello は、 TLS のハンドシェイクプロセスの最初の方にやり取りされるメッセージである。

目的

複数のサイトを持つ一つのサーバが、複数の電子証明書を使い分けられるようになることを目的とする。

経緯

自分にとって馴染みがあるという理由で、 HTTP を例に説明する。

HTTP/1.1 の Name-based Virtual Host では、HTTP リクエストでやり取りされる Host - HTTP | MDN (mozilla.org) ヘッダーの情報を読み取ることで実現している。

ここに記載されているホスト名を元に、表示するサイト (ホスト) を振り分けている。

しかし HTTPS ではこの手段を利用することはできない。TLS のコネクション確立時点でリクエストされているサーバ名を判別し、適切な証明書を送らねばならないからである。しかし、 TLS のレイヤから HTTP のレイヤを読み取ることはできない。TLS (TCP) のレイヤにとって HTTP のレイヤ (アプリケーションレイヤ) は単なるペイロードであるため、解析して情報を取得することができない。

SNI なしでは、Server はすべてのリクエストに対し一つの証明書を送る他なかった。このため、HTTPS でのバーチャルホストの実現などが難しかった。

SNI が実装されたことにより、HTTPS においてもバーチャルホストが簡単に利用できるようになった。