文章や画像などを自動作成する生成AIは各分野で活用が進む一方、サイバー攻撃に悪用されていることは知られていない。用途はコンピュータウイルスや詐欺メール、偽動画の作成など多岐にわたり、国内でも摘発事例が発生した。AIで攻撃側の効率化が進めば、被害の頻度や範囲は一気に増加・拡大する恐れがある。自律的な攻撃を仕掛ける“人格”を持ったAIの登場も「時間の問題」（専門家）とされる。
「組織はユーザーに定期的なパスワード変更を要求してはならない」──米国政府機関の米国立標準技術研究所（NIST）が、そんな内容を含めた新しいガイダンス「SP800-63B」を発表した。パスワードの内容は、セクション3.1.1に記されている。
“パスワード変更”をユーザーに定期的に要求はダメ 米国政府機関が発表 「大文字や数字を入れろ」の強制もNG：Innovative Tech - ITmedia NEWS
⇧ セキュリティ対策の進展よりも、サイバー攻撃の発展の方が上回っていきそうなんですかね？
いつの世も、
ダイナマイト（英: dynamite）は、ニトログリセリンを主剤とする爆薬の総称。アルフレッド・ノーベルが最初に発明したのはニトログリセリンを珪藻土にしみ込ませたもの。現代の日本においては、一般社団法人火薬学会の規格では6%をこえるニトロゲル（後述のゼリグナイト）を含有する爆薬の総称と規定されている。
歴史
ノーベルは本来は土木工事の安全性向上を目的としてダイナマイトを発明したのであり、それが戦争に用いられたのはその意志に反していたという風聞があるが、実際にはノーベルにとってダイナマイトが戦争目的で使われることは想定内であった。
むしろノーベルは、ダイナマイトのような破壊力の大きな兵器が使われることで、それが戦争抑止力として働くことを期待した。
⇧ 人間の悪意が、画期的な成果物を台無しにしてくれるということですかね...
哀しいけれど、悪用され続けるんでしょうね...
Azure Key Vaultとは
公式のドキュメントによりますと、
Azure Key Vault の基本的な概念
Azure Key Vault は、シークレットを安全に保管し、それにアクセスするためのクラウド サービスです。 シークレットは、API キー、パスワード、証明書、暗号化キーなど、アクセスを厳密に制御する必要がある任意のものです。 Key Vault サービスでは、ボールトおよびマネージド ハードウェア セキュリティ モジュール (HSM) プールという 2 種類のコンテナーがサポートされています。 ボールトでは、ソフトウェアと HSM でバックアップされるキー、シークレット、証明書を保存できます。 Managed HSM プールは、HSM でバックアップされるキーにのみ対応しています。 詳細については、Azure Key Vault REST API の概要に関するページを参照してください。
https://learn.microsoft.com/ja-jp/azure/key-vault/general/basic-concepts
認証
Key Vault で操作を行うには、まず、それを認証する必要があります。 Key Vault に対する認証には 3 つの方法があります。
- Azure リソースのマネージド ID:Azure の仮想マシンにアプリをデプロイするときに、Key Vault にアクセスできる仮想マシンに ID を割り当てることができます。 他の Azure リソースにも ID を割り当てることができます。 この手法の利点は、最初のシークレットのローテーションがアプリやサービスで管理されないことにあります。 Azure では、ID が自動的にローテーションされます。 ベスト プラクティスとして、この手法をお勧めします。
- サービス プリンシパルと証明書: サービス プリンシパルと、Key Vault にアクセスできる関連証明書を使用することができます。 アプリケーションの所有者または開発者が証明書をローテーションする必要があるため、この手法はお勧めできません。
- サービス プリンシパルとシークレット: サービス プリンシパルとシークレットを使用して Key Vault に対する認証を行うことはできますが、これはお勧めできません。 Key Vault に対する認証で使用されるブートストラップ シークレットを自動的にローテーションするのは困難です。
https://learn.microsoft.com/ja-jp/azure/key-vault/general/basic-concepts
⇧ とあり、「Azure Key Vault」向けのAPIを利用するための「認証」には3つの方法がありますと。
Azure Key Vaultの情報を取得するにはAzureのサービスを経由してアクセスする必要があるらしいが、Azureのサービスを利用するための認証の概要をお浚い
そもそも、外部からAzureのサービスを利用する仕組みって？
Azure Resource Manager とは
Azure Resource Manager は、Azure のデプロイおよび管理サービスです。 お使いの Azure アカウント内のリソースを作成、更新、および削除できる管理レイヤーを提供します。 アクセス制御、ロック、タグなどの管理機能を使用して、デプロイ後にリソースを保護および整理します。
https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/overview
一貫性のある管理レイヤー
ユーザーが Azure API、ツール、または SDK のいずれかを介して要求を送信すると、その要求はリソース マネージャーによって受信されます。 要求は、認証および承認された後、適切な Azure サービスに転送されます。 すべての要求は同じ API を介して処理されるため、すべての異なるツールで一貫した結果と機能が得られます。
https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/overview
次の図は、Azure 要求の処理において Azure Resource Manager が果たす役割を示しています。
https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/overview
⇧ 上図を見た感じ、Azureのサービスを利用するための「認証」については「Azure Resource Manager」が一手に担っている模様。
つまり、
- Azure Portal
- Azure PowerShell + SDKs
- Azure CLI + SDKs
- Rest Clients
どの方法にしろ、「認証」のためのリクエストの送信先である「エンドポイント」は同じになるってことですかね。
Azureのサービスを利用するための認証のためのエンドポイントは大きく分けて2つ？
で、相変わらずMicrosoftのドキュメントが整理されていなくて辛いのだが、
⇧ 上記サイト様によりますと、ベースとなるホストが2種類用意されているらしく、
- Microsoft Entra ID
→ https://login.microsoftonline.com/ - Azure Instance Metadata Service (IMDS)
→ http://169.254.169.254
という感じらしい。
うむ、トークン取得のリクエストに関する制約が全く分からん...
IMDS is a REST API that's available at a well-known, non-routable IP address (169.254.169.254). You can only access it from within the VM. Communication between the VM and IMDS never leaves the host. Have your HTTP clients bypass web proxies within the VM when querying IMDS, and treat 169.254.169.254 the same as 168.63.129.16.
https://learn.microsoft.com/ja-jp/azure/virtual-machines/instance-metadata-service?tabs=windows
⇧ 何と言うか、「認証」の実装のパターンの全量が分からないんだが、「一貫性のある管理レイヤー」の図になるように、「認証」部分は1つに集約できなかったんか...
Azureで用意されている「REST API」が利用できるようにするまでに必要な情報が分かり辛いんよな...
2024年10月8日（火）追記：↓ ここから
何やら、
⇧ stackoverflowによると、「http://169.254.169.254」については、Azure外からアクセスできないらしい...
Azureの公式のドキュメントに記載しといて欲しいよね...
2024年10月8日（火）追記：↑ ここまで
Azure外からAzure Key Vaultの情報を取得するにはAzure サービス経由でアクセスする必要がある？
チュートリアルだと、
Linux VM のシステム割り当てマネージド ID を使用して Azure Key Vault にアクセスする
このチュートリアルでは、Linux 仮想マシン (VM) でシステム割り当てマネージド ID を使用して Azure Key Vault にアクセスする方法について説明します。
Key Vault により、クライアント アプリケーションは、Microsoft Entra ID で保護されていないリソースにシークレットを使ってアクセスできます。 マネージド サービス ID は Azure によって自動的に管理され、認証情報をコードに含めなくても、Microsoft Entra 認証をサポートするサービスに対して認証を行うことができます。
⇧「Azure Instance Metadata Service (IMDS)」のエンドポイントを利用しているっぽいと思われますが、Azure側では、
- Microsoft Entra ID
- Azure アカウント ※1
- Azure Virtual Machine
- Azure Key Vault
の4つ用意が必要と。
※1 以下、どちらのマネージドIDを利用するかで必要な権限が変わる。
| No | 項目 | 必要な権限 |
|---|---|---|
| 1 | システム割り当てマネージド ID | 仮想マシン共同作成者ロール |
| 2 | ユーザー割り当てマネージド ID | 仮想マシン共同作成者ロール |
| マネージド ID オペレーター ロール |
2024年10月8日（火）追記：↓ ここから
どうやら、
⇧「Azure Key Vault」が「マネージドID」を使用した他Azureサービスへのアクセスに対応していないから、
⇧「Azure Virtual Machines」に「マネージドID」を割当てて、「Azure Virtual Machines」経由で「Azure Key Vault」にアクセスする感じなんですかね？
2024年10月8日（火）追記：↑ ここまで
ドキュメントの方だと、
Azure Key Vault の認証
Key Vault による認証は、特定のセキュリティ プリンシパルの ID の認証を行う Microsoft Entra ID と連携して機能します。
https://learn.microsoft.com/ja-jp/azure/key-vault/general/authentication
セキュリティ プリンシパルは、Azure リソースへのアクセスを要求するユーザー、グループ、サービス、またはアプリケーションを表すオブジェクトです。 すべてのセキュリティ プリンシパルには、Azure によって一意のオブジェクト ID が割り当てられます。
-
ユーザー セキュリティ プリンシパルでは、Microsoft Entra ID 内にプロファイルを持つ個人が示されます。
-
グループ セキュリティ プリンシパルでは、Microsoft Entra ID 内に作成されたユーザーのセットが示されます。 グループに割り当てられたすべてのロールまたはアクセス許可は、グループ内のすべてのユーザーに付与されます。
-
サービス プリンシパルは、アプリケーションまたはサービス、つまりユーザーまたはグループではなくコードを示すセキュリティ プリンシパルの一種です。 サービス プリンシパルのオブジェクト ID は、そのユーザー名のように機能します。サービス プリンシパルのクライアント シークレットは、そのパスワードのように動作します。
https://learn.microsoft.com/ja-jp/azure/key-vault/general/authentication
⇧「セキュリティプリンシパル」とか出てきて、わけ分からん...
とりあえず、
Key Vault の認証は、Key Vault に対するあらゆる要求操作の過程で行われます。 トークンは、いったん取得されると、後続の呼び出しで再利用することができます。
https://learn.microsoft.com/ja-jp/azure/key-vault/general/authentication
次の図は、アプリケーションが Key Vault の "シークレットの取得" API を呼び出すプロセスを示したものです。
https://learn.microsoft.com/ja-jp/azure/key-vault/general/authentication
⇧ 何某かのAzureのサービス（Azure Virtual Machineなど）、図で言うところの「Service Principal」を経由することで、「Microsoft Entra ID」で「Azure Key Vault」のサービスに対するAPIを利用するための「認証」が行われ、「認証」が済めば「Azure Key Vault」のサービスに対するAPIを利用できるようになると。
オンプレミス環境などの、所謂、Azureの外部からのリクエストなども、「Service Principal」を経由させる必要があるってことなんかね？
Azure Key VaultへのアクセスってIPアドレスのホワイトリストで制限する感じになるのか
で、気になったのが、「Azure Key Vault」のサービス自体へのアクセスを制御できないのか？
公式のドキュメントによると、
⇧ IPアドレスで制御できるとのこと。
まぁ、アプリケーションが稼働しているサーバーが1000台とかであれば、IPアドレスをホワイトリスト化して、制限すれば良さそうではありますが。
それにしても、相変わらず、Microsoftはドキュメントが整備されていない感じですな...
「ファインダビリティ（Findability）」が酷過ぎて絶句するしかないんだが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
