https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d3-infra-03
最新 Google Cloud ネットワークアーキテクチャ設計のコツ (2021年版)
Google Cloud では新しいサービスや機能がどんどん出てきていますが、そのような最新のサービスや機能を使うことで、より効率的に、より安全にインフラストラクチャの設計をおこなっていただけるようになっています。本セッションでは、そのような最新のサービスや機能をご紹介しつつ、それを活用した最新のインフラストラクチャ設計のコツをご案内します。

質問	内容
階層型ファイアウォールポリシーで、プロジェクトごとのファイアウォールルールと組織で決めたファイアウォールルールは通常通り優先度を設定して優先度を決めるように見えましたが、組織で決めたファイアウォールルールを強制することもできますか。	こちらのページ https://cloud.google.com/vpc/docs/firewall-policies#rule-evaluation の図にあります通り、階層型ファイアウォールのルール(= 組織で決めたルール)が優先されるます。
	逆に VPC ファイアウォールを階層型ファイアウォールに対して優先させることはできません
Private Service Connect でAPIサービスへのアクセスできるようになったのは分かったのですが、既存の方法との使い分けとかはあるのでしょうか？	すでにこれまでの方法で設定・運用されている場合はすぐに変更する必要はないですが、これから設計される場合は Privatre Service Connect による接続をオススメいたします。
省略された仮想アプライアンスの冗長化に関して、参考になるページはありますか？	次のページで内部ロードバランサーと組み合わせて、仮想アプライアンス等を冗長化する方法をご案内しています。 https://cloud.google.com/load-balancing/docs/internal/ilb-next-hop-overview
ネットワークのガバナンスを効かせる場合、共有VPCを利用するのと、階層化FWを利用するの、どちらがおすすめでしょうか？	共有VPCではネットワークの管理をインフラチームが一括することで、アプリ/システム開発チームがインフラの管理を意識しないで済むという責任分担が実現できます。
	一方、階層化FWでは、インフラチームが複数あった場合に、組織(会社)全体としてのネットワークアクセスポリシーの一元化を実現可能になります。このように、共有VPC、階層化FWを組み合わせて、全体としてのガバナンスを実現いただけるものと思います。
UserAgentが偽装されててもAdaptiveProtection可能ですか	偽装された User Agent を含むトラフィックが有意に通常のトラフィックと異なっており、Adaptive Protection によって攻撃と判断された場合は、当該 User Agent を含むトラフィックをブロックするようなルールが提示される可能性が高くなります。
Cloud Armor は OWASP のルールセットが使われている認識ですが、Adaptive Protection はそのルールセットをオーバーラップする感じでしょうか？	Cloud Armor の Adaptive Protection は、攻撃と判断したトラフィックをブロックするためのルールを提示し、ユーザーがそのルールを実際に適用する、という運用になります。一方、OWASP 由来の攻撃を防ぐのも同じくルールになります。
	ルールは優先度を持っており、優先度が高いルールから適用されますので、OWASP 由来のルールと、Adaptive Protection が生成したルールと、どちらの優先度を高くするかによって、どちらのルールが適用されるかが決まります。
	Cloud Armor のルールの優先度についてはこちらのページをご参照ください https://cloud.google.com/armor/docs/security-policy-overview#eval-order

切り口	内容
private service connect
階層型FWポリシー
ネットワーク仮想アプライアンス	httpの中にこういう記載があったらだめ、というところも設定できる。
共有VPC	VPCをたくさん作る必要がなくなる
ネットワーク仮想アプライアンスと共有VPCの組み合わせ
CloudArmor	自分たちでDDOS対策の設定をしないといけなかったが、不審な挙動を分析して提案してくれるようになった。