2022-06-27

2022-06-27 Unix Domain Socket について調べた

Unix Domain Socket とは、同一ホスト上でのプロセス間通信におけるデータのエンドポイントである。

C言語から利用される場合は、以下のように利用される。

struct sock_addr_un {
    sa_family_t sun_family;
    char        sun_path[108];
}

また、下記のサイトで実際にプロセス間通信を動作させることができた。

サーバ側のコードを実行すると /tmp/test.unixsocket というパスに unix domain socket が作成される。

クライアント側のコードを実行してメッセージを入力すると、その unix domain socket を利用してサーバとクライアントが通信を行う。

C言語ソケット通信サンプル(UNIXドメイン) | 底辺プログラマーの戯言 (mathkuro.com)

使い方は以下の通り。環境は Ubuntu の 18.04 である。

それぞれのファイルについて、 server.c, client.c という名前で保存しておく。

片方のプロセスで、以下を実行。

gcc ./server.c -o server
./server

もう片方のプロセスで、以下を実行。

gcc ./client.c -o client
./client

クライアント側でメッセージを入力すると、サーバ側に入力内容が出力される。楽しい。

2022-06-27

2022-06-27 udev について調べた

dev 日々の学習記録

userspace /dev。Linux Kernel のデバイスマネージャである。

昔は Device File System (DevFS) というデバイスマネージャを使っていた。これを置き換えたのが、 udev である。

DevFS が kernel space で動作するのに対し、user space で動作することが特徴。

構成

いくつかの kernel service と、 udevd で構成される。

ディスクの接続、切断などのイベントが発生すると、 kernel service 側から udevd へ通知が飛ぶ。

udevd がこの通知をハンドリングして Action を実行する。この Action が user space で行われるため、 udev は user space で動作する。

Action の内容は rules に従って行われる。この rules は /etc/udev/rules.d/ ディレクトリ以下などに格納されており、ユーザが任意に設定することも可能である。

2022-06-27

2022-06-27 Google Certified Cloud Security Engineer 模擬試験

日々の学習記録

Organization 関連の Role 割り当て

問題

お客様が、会社のアプリケーションを Google Cloud に移行しようとしています。セキュリティチームは、組織内のすべてのリソースを詳細に把握する必要があります。あなたは Resource Manager を使って自分を組織管理者に設定しています。セキュリティチームには、どのような Cloud Identity and Access Management（Cloud IAM）のロールを付与する必要がありますか？

回答

組織閲覧者、プロジェクト閲覧者

解説

権限は最小限とするのがベストプラクティス。

Organization 関連のロール

roles/resourcemanager.organizationAdmin

組織管理者。組織に関する諸々の設定変更を行うことができる。

roles/resourcemanager.organizationViewer

組織閲覧者。 roles/browser と異なる点として、Organization Policy の閲覧ができる点がある。

roles/orgpolicy.policyAdmin

組織のポリシー管理者。組織のポリシー (組織全体にかける制限など) の管理が行える。

roles/browser

組織に関する設定の閲覧ができる。組織のポリシーについての閲覧はできない。

Access control for organizations with IAM | Resource Manager Documentation | Google Cloud

IAM

who (user) has what access (roles) to which resources という構成になっており、これのそれぞれを IAM Policy と呼称する。

User に permission を直接割り当てるのではなく、まず Roles を作成しそれに Permission を割り当て、 Roles を User に割り当てることで、間接的に User に Permission を割り当てる。

コンテナ関連のセキュリティ

問題

あなたの会社は、コンテナイメージ内のパッケージの CVE 情報を収集、分析し、セキュリティ上の既知の問題があるイメージは、Google Kubernetes Engine 環境で実行されないようにしたいと考えています。コンテナビルドパイプラインに、どのようなセキュリティ機能を導入すればよいですか？2 つ選択してください。

回答

デプロイポリシー、脆弱性スキャン

解説

脆弱性スキャンは Container Analysis という機能であり、 Container Registory, Artifact Registory に登録されているイメージの脆弱性スキャンが行える。

Container Analysis documentation | Google Cloud

デプロイポリシーは、 Binary Authorization という機能で実現される。

Binary Authorization

「サプライチェーンの Security を保持する」ことが目的のサービスと説明されている。

サプライチェーンとは Container Registory 等のイメージのレジストリ、およびデプロイに使われる CI、さらにデプロイ先の Kubernetes, SaaS 等のアプリケーションまで含む、コンテナのサプライチェーンのことを指すと理解した。

例えばコンテナのデプロイにおいては、デプロイされるコンテナについての policy を定義し、デプロイされようとするコンテナがその policy を満たすかをチェックする。

policy は一つまたは複数の rules を含むため、それらに合致されているかが確認される。

Binary Authorization overview | Google Cloud

Exempt Images

Binary Authorization における policy のチェックから除外するイメージを指定する。

Exempt という単語は何らかの義務や支払いを免れるという意味であり、ここでは policy のチェックを免れるという意味である。

2022-06-24

2022-06-24 Google Certified Professional Cloud Security Engineer 模擬試験

日々の学習記録

Cloud IAP

問題

ある組織が最近、顧客向けのウェブアプリケーションを構築、ホストするために、App Engine を使用し始めました。この組織は、既存の IAM 設定を使用して、デベロッパーがアプリケーションへの昇格されたアクセス権をリモートで利用できるようにしたいと考えています。こうすることで、デベロッパーは HTTPS 接続を介して、更新プログラムや修正プログラムをアプリケーションにプッシュできるようになります。デベロッパー以外の従業員には、開発権限なしで、本番環境バージョンへのアクセス権のみを付与する必要があります。この要件をクリアするためには、どの Google Cloud ソリューションを使用すればよいですか？

回答

Cloud Identity-Aware Proxy（Cloud IAP）を設定して、従業員によるアクセスの認証やさまざまな承認レベルを管理する。

解説

コンセプトについての説明では、Cloud IAP について十分に理解することができなかった。stackoverflow で紹介されていた以下ページを参照しようやく理解できた。

Quickstart: Authenticate users with Google Accounts | Identity-Aware Proxy

Cloud IAP の App Engine でのユースケース

信頼されたユーザ

Cloud IAP を有効にし、そこにユーザを追加する。

追加されたユーザは、Cloud IAP において「信頼されたユーザ」として扱われる。

それ以外のユーザは、「信頼されていないユーザ」として扱われる。

IAP による AppEngine の保護

Cloud IAP で、保護するアプリケーションを選択する。

こうすることによって、信頼されたユーザは AppEngine にアクセスでき、信頼されていないユーザは AppEngine にアクセスできないというアクセス管理が実現できる。

Google にログインしていないユーザがアクセスした場合は Cloud IAP によってリダイレクトが行われ、ログインページが表示される。

想定されるユースケース

自社の社員のみが利用することを想定している AppEngine のアプリケーションがある場合、 Cloud IAP を利用することで、簡単にアクセスを自社の社員のみに絞ることができる。

アプリケーション側でアクセスを絞る機能を作成する必要がなくなる。また、 Cloud IAP があるためアプリケーションは全公開とすることができる。

送信元アドレスに制限をかける、 VPN 経由で接続する等のソリューションが不要となる。

また、自社の社員のうち、一部の社員のアクセスを絞りたい場合は、 Cloud IAP の管理画面からポチポチとユーザの追加、削除を行うことでその管理を行うことができる。

Shared VPC

問題

Google Cloud 内の VPC でサブネットを定義しました。複数のプロジェクトで、このサブネットの IP アドレスを使用して Compute Engine インスタンスを作成する必要があります。何をすべきですか？

回答

共有 VPC を使用して、サブネットを他のプロジェクトと共有する。

解説

サブネットの異なるプロジェクト間での共有は、共有 VPC によって行う

Shared VPC overview | Google Cloud

Cloud DLP における、秘匿化のカスタム検出器作成

問題

メールアドレスなどの顧客 ID を含むアプリケーションのログデータを秘匿化する必要があります。ただし、このログには社内のデベロッパーのメールアドレス（company.com）も含まれており、それらは秘匿化しないようにします。この要件をクリアするためには、どのソリューションを使用すればよいでしょうか？

回答

正規表現（regex）のカスタム infoType 検出器を作成し、@company.com を照合する。

解説

全く知らなかった機能だが、GCP には Cloud Data Loss Prevention (Cloud DLP) という機能があるらしい。

データウェアハウスに保存されているデータから機密データを検出したり、それらの機密データについて自動的にマスキングを行ったり、個人を特定できるような組み合わせとなっているデータを検出したりすることができる。

機密データの保管に関する総合的なソリューションのように感じた。

ここでは触りだけとし、詳しくは Google Skills Boost で学びたい。ドキュメントは以下。

InfoType detector reference | Data Loss Prevention Documentation | Google Cloud

Creating custom infoType detectors | Data Loss Prevention Documentation | Google Cloud

Cloud Storage におけるデータの保護

問題

Cloud Storage のデフォルトの暗号化では、どの暗号化アルゴリズムが使用されますか？

回答

AES-256

解説

標準では暗号化アルゴリズムとして AES-256 が利用される。

サーバ側暗号化は自動的に、また必ず行われる。それによる追加料金やパフォーマンスの低下は発生しない。

通常、Cloud Storage を利用するユーザがこの暗号化処理を意識することは少ないと思われる。

Google-managed encryption keys | Cloud Storage

Cloud Storage における保持期間の指定

問題

あなたの会社は Cloud Storage にファイルを保管しています。地域の規制を遵守するために、アップロードしたファイルは、以降 5 年間は削除できないようにする必要があります。設定した保持期間は、後から短縮できないようにする必要もあります。何をすべきですか？

回答

5 年間の保持期間をバケットに適用し、バケットをロックする。

解説

保持期間の設定は、「data retension policy」として設定することができる。

また、設定したポリシーをロックすることで、「設定した保持期間は、後から短縮できないようにする」という要件を満たすことができる。

ポリシーをロックすることで、ポリシーが不意に変更されることを防ぎ、データの保護を確実とすることができる。

一度行ったロックは解除することが不可能となる。バケットを削除するしかないが、そのバケットの削除も条件が厳しく、最悪もう利用しない、削除したいバケットについて、保持期間が終わるまでずっと望まない課金を行い続けることになる。適用は慎重に行うこと。

Retention policies and retention policy locks | Cloud Storage | Google Cloud

コンテナイメージへのセキュリティパッチ適用

問題

あなたの会社は、Google Kubernetes Engine にアプリケーションをデプロイしています。Google が推奨する方法に沿って対応する場合、新しいデプロイで使用するコンテナイメージに、確実に最新のセキュリティパッチを含めるためには、どうすればよいですか？

回答

すべてのコンテナで Google が管理するベースイメージを使用する。

解説

この問題の解説では、https://cloud.google.com/container-registry/docs/managed-base-images というページにリンクが貼られていたが、そのページは現在リンク切れとなっている。

同様のページもないため、 Google はこの managed-base-images の提供をやめたのかもしれない。

https://cloud.google.com/container-registry/docs/container-best-practices

2022-06-23

2022-06-23 Google Certified Professional Security Engineer 模擬試験

日々の学習記録

引き続き模擬試験について振り返りを行っている。

デフォルト VPC のファイアウォールルール

問題

インバウンドとアウトバウンドのすべてのインターネットトラフィックから、デフォルトの VPC ネットワークを保護する必要があります。どうすればよいですか？

回答

すべてのアウトバウンドトラフィックを拒否するファイアウォールルールを作成する。

解説

デフォルトの VPC ネットワークでは、インバウンドのトラフィックは全てブロック、アウトバウンドのトラフィックはすべて許可する設定となっている。

そのため、アウトバウンドのトラフィックを拒否するファイアウォールルールを作成することで、インバウンドとアウトバウンドのすべてのインターネットトラフィックから保護することができる。

Cloud Identity Aware Proxy の構成

問題

回答

Cloud Identity-Aware Proxy（Cloud IAP）を設定して、従業員によるアクセスの認証やさまざまな承認レベルを管理する。

Cloud NAT

インスタンスに外部 IP を付与することなく、外部との通信を行うことができる。

Cloud Identity Aware Proxy

Cloud Identity Aware Proxy (IAP) は、認証を行うサービス。組織に適用され、プロジェクトやリージョンを超えてグローバルレベルで有効になる。

IAP を使うことで、 App Engine アプリのユーザ条件に基づいて様々なレベルのアクセス権を確立できる。

開発者は、更新プログラムや修正プログラムを push するアクセスを得られる。

開発者でない従業員は、本番環境へのアクセスのみを得られる。

2022-06-22

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

日々の学習記録

Google Cloud Professional Cloud Security Engineer 模擬試験の解説

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

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

既存の IdP の利用

問題

あるお客様が、Google Cloud でソリューションを開発する際に、ネイティブ認証の要件がある既存のユーザーディレクトリを使用したいと考えています。また、既存のツールと機能を利用して、使い慣れたインターフェースからユーザーのアクションに関する分析情報を収集したいと考えています。このお客様の要件を満たすためには、どうすればよいですか？

(A customer needs to rely on their existing user directory with the requirements of native authentication when developing solutions in Google Cloud. They want to leverage their existing tooling and functionality to gather insight on user activity from a familiar interface. Which action should you take to meet the customer's requirements?)

回答

お客様のユーザーディレクトリを ID プロバイダとして使用し、Cloud Identity を SAML 2.0 サービスプロバイダに設定する。

解説

問題文を分解する。

「ネイティブ認証の要件がある既存のユーザーディレクトリ」を使用したい
「ユーザーのアクションに関する分析情報を収集」したい

重要なのはこの二つ。

「ネイティブ認証の要件がある既存のユーザディレクトリを使用したい」というのは、GCP の Google Identity を利用したり、他の IdP を新規にセットアップして認証を行ったりしたくはないということ。

その要望は、顧客の既存のユーザディレクトリを IdP として使用することで叶えられる。

「ユーザのアクションに関する分析情報を収集したい」というのはドキュメントに記載がなかったが、 OpenLDAP などはユーザのログイン / ログアウトについてログを吐いたりするそうなので、顧客の既存のユーザディレクトリを使うことでその要望は叶えられるということではないかと解釈した。

あまり後者については回答の選択に関わってこない。

ユーザディレクトリ

ユーザやグループの情報を格納しておくところ。アクティブディレクトリのようなもの。

アクティブディレクトリ

ディレクトリサービスの一種。 Windows 端末をドメインコントローラによって一括管理する。

ディレクトリサービス

コンピュータネットワーク上のリソース（資源）とその所在や属性、設定などの情報を収集・記録し、検索できるようにしたサービス。

AD や LDAP の他、 DNS もおそらく該当する。

ネイティブ認証

おそらく、外部サービスに依存せず自身で認証を行うことを、 Native Authentication と呼称しているのではないかと理解した。

mysql であれば MySQL :: Security in MySQL :: 6.1.1 Native Pluggable Authentication に「Native Pluggable Authentication」というのが記載されており、それはユーザ名およびパスワードの組によって、自データベースで認証を行うものだった。

また、 ORACLE にも Using NATIVE authentication (oracle.com) というのがあり、これもまたユーザ名およびパスワードによって自データベースにユーザ名とパスワードを保存、自ら認証を行うものだった。自分自身で完結する認証。

ここでは、 Google Cloud の IdP を利用するのではなく、既存のユーザディレクトリ自身の認証機能を用いて認証を行うことを指しているのだろうと思う。

Google Cloud Directory Sync

LDAP 系のシステムから Cloud Identity に対して定期的に Identity を同期するツール。クライアントソフトのようなものが用意されているらしい。

同期元の LDAP 系のシステムの Identity のデータは変更されず、 Google Identity 側が同期される形で変更される。

Third-party IdP connector

SAML SSO というものを使って、 third-party 製のアプリから LDAP のユーザやグループ情報を GCP に同期する。

この場合、 GCP の console にログインする際の認証についてもその LDAP の認証によって行われるようになる。

SAML SSO

SAML SSO を設定すると、GCP のリソースにアクセスした際は GCP がページを連携先の IdP にリダイレクトする。

このリダイレクト先の URL を Admin Console から指定することで、 SAML SSO の設定が行える。

サービスアカウントの利用

問題

あるお客様が、Compute Engine で実行されているアプリケーションにアクセス権を付与し、書き込み対象を特定の Cloud Storage バケットに限定したいと考えています。どのようにアクセス権を付与すればよいですか？

回答

そのアプリケーション用のサービスアカウントを作成し、バケットレベルで Storage オブジェクト作成者のロールを付与する。

解説

Compute Engine にリソースへのアクセス権を割り当てる際は、ユーザアカウントでなくサービスアカウントに割り当てることが適切である。

Compute Engine とサービスアカウント

Compute Engine のインスタンスに、それぞれサービスアカウントを割り当てることができる。

割り当てるサービスアカウントは後からでも変更することができる。

ファイアウォール利用の制限

問題

あなたのチームが、自社の IP 範囲内から、Compute Engine 上の特定の踏み台インスタンスへの SSH アクセスを許可するため、上り（内向き）ファイアウォールルールを作成しています。あなたのチームは、未承認のエンジニアは、このファイアウォールルールを使用できないようにしたいと考えています。そうしないと、未承認のエンジニアが開発環境内で VM を管理するアクセス権を取得する可能性があるからです。この要件を満たすためには、どうすればよいですか？

回答

サービスアカウントをターゲットに設定してファイアウォールルールを作成し、そのサービスアカウントへのアクセスを一元管理する。

解説

B が正解です。サービスアカウントをターゲットに設定したファイアウォールルールを使用するためには、サービスアカウントへのアクセスが必要になるからです。

承認済みのエンジニアに対して、サービスアカウントをターゲットとしたアクセスの許可を設定する。

ファイアウォールルールについてそのサービスアカウントを割り当てることによって、承認済みのエンジニアがファイアウォールルールを閲覧、編集できるようにする。

サービスアカウントに対する閲覧の権限を持たない未承認のエンジニアは、ファイアウォールルールにアクセスできず使用できない状態となる。

サービスアカウント vs ネットワークタグ

今回のようなファイアウォールルール含むインスタンスへのアクセス制御については、サービスアカウントによって実現する方法と、ネットワークタグによって実現する方法がある。

結論として、サービスアカウントを利用するほうがよい。

ネットワークタグは、インスタンスのタグの編集権限を持っている人であればどのタグでも付与できてしまうという問題があるからである。

インスタンスが、サービスアカウントを利用するように構成する。そして、そのサービスアカウントへのアクセス権限をユーザアカウントに割り当てることで、そのインスタンスのファイアウォールルールに対するアクセスを制御することができる。

今回であれば、「特定の踏み台インスタンス」がサービスアカウントを利用するように構成する。

そして、承認されたエンジニアのグループに対してこのサービスアカウントへのアクセスを許可する。

2022-06-21

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

日々の学習記録

Google Cloud Professional Cloud Security Engineer 模擬試験の解説

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

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

Cloud Identity による一括管理

問題

ある組織のデベロッパーが Google Cloud でいくつかのアプリケーションのプロトタイピングを行っており、Google Cloud に機密情報を保管することにしました。デベロッパーは、個人用 / 一般ユーザー向けの Gmail アカウントを使用して、Google Cloud 内でプロジェクトを設定、管理しています。セキュリティエンジニアは、プロジェクトが一元管理されていないことと、そうしたアカウントに保管されているデータへのアクセスの面から、その手法が経営陣にとっての懸念事項になっていることを確認しました。この問題を解決するには、どのソリューションが効果的ですか？

回答

Cloud Identity を設定して、デベロッパーに対し、Google Cloud での作業には対象のアカウントを使用するよう義務付ける。

解説

アカウント管理についての Google のベストプラクティスは、 Cloud Identity を利用した一括管理。

Google Workspace を利用して雇用先でも行っていることであり、なじみ深いやつ。

Cloud Identity とサードパーティアプリケーションとの連携

問題

あるお客様が、Cloud Identity を主要 IdP として使用したいと考えています。このお客様は、CRM やメッセージング、顧客チケット発行管理などで、Google Cloud 以外の SaaS プロダクトも使用したいと考えています。また、シングルサインオン（SSO）機能で、Google Cloud や Google Cloud 以外のアプリケーションへのアクセスを保護することで、従業員エクスペリエンスも改善しようとしています。それにより、承認済みのユーザーのみ、そうしたサードパーティのアプリケーションにアクセスできるようにします。このお客様がこうした要件をクリアするためには、どのようなアクションが求められますか？

回答

サードパーティアプリケーションの設定で、Google Cloud IdP の認証および承認を連携するよう指定する。

解説

IdP とは以前調べた通り Identity Provider のこと。

主の IdP として Cloud Identity を利用し、サードパーティのアプリケーションを SAML、もしくは OIDC によって連携させることがベストプラクティスである。

それによって、ユーザアカウントの一括管理、自動プロビジョニングを行うことができる。 IdP 側でユーザアカウントを作成するとサードパーティ側のアプリケーションにおいてもユーザのアカウントが作成され、同様に削除するとサードパーティ側のアプリケーションにおいても削除される。

ただし、この方法を行うためには Cloud Identity 側にそれぞれのアプリに対応した「自動プロビジョニングコネクタ」というものがある必要がある。これがないアプリについては、SAML の設定のみで簡易に利用することができる JIT (Just In Time) プロビジョニングというものを利用するのがよい。

ただし JIT はユーザのプロビジョニングのみで、ユーザのプロビジョニング解除がサポートされていない。そのため、退職者が出た場合の、アプリからのユーザアカウント削除については手動で行う必要がある。

可能であれば、サービスプロバイダと協力して、 Cloud Indentity に対応したコネクタを開発することが推奨される。

コネクタを持つアプリケーションの一覧は以下にある。

https://support.google.com/cloudidentity/topic/7661972

既存の IdP の利用

問題

回答

お客様のユーザーディレクトリを ID プロバイダとして使用し、Cloud Identity を SAML 2.0 サービスプロバイダに設定する。

解説

問題文を分解する。

「ネイティブ認証の要件がある既存のユーザーディレクトリ」を使用したい
「ユーザーのアクションに関する分析情報を収集」したい

重要なのはこの二つ。

ユーザディレクトリ

ユーザやグループの情報を格納しておくところ。アクティブディレクトリのようなもの。

アクティブディレクトリ

ディレクトリサービスの一種。 Windows 端末をドメインコントローラによって一括管理する。

ディレクトリサービス

コンピュータネットワーク上のリソース（資源）とその所在や属性、設定などの情報を収集・記録し、検索できるようにしたサービス。

AD や LDAP の他、 DNS もおそらく該当する。

ネイティブ認証

おそらく、外部サービスに依存せず自身で認証を行うことを、 Native Authentication と呼称しているのではないかと理解した。

終わり

今日はここまで。「ユーザーのアクションに関する分析情報を収集」することについては引き続き後日実施する。