はじめに
Azure Files共有をストレージアカウントのアクセスキーでマウントする操作で、どちらのキーを利用しているか追うことは可能か?を調査いたしました。
どうやら診断ログの「identity」項に記録されるとのことで(公開情報はこちらです:Azure Files 監視データのリファレンス | Microsoft Learn)実際に動作検証をした記録です。
ストレージアカウントのアクセスキーとは
アクセスキーとは、ストレージアカウントに管理者権限で接続するためのパスワードです。
Azure Portal上で権限のあるアカウントであれば[ストレージアカウント]>[アクセスキー]で文字列を確認することができます。
ストレージアカウントがデフォルトのパブリックアクセスが可能でも、このアクセスキーを入手することが出来なければBlobやAzure Files共有等の中にあるデータを取得することができません。
セキュリティをより高めるためには、アクセスキーをAzure Key Vaultで管理することが推奨されます。
そして、パブリックアクセスではなく接続元を制限するか、プライベートエンドポイントを設定することで通信元を制御することが望ましいです。
Azure Filesをマウントする際は、以下で認証します。
- アカウント名:localhost\[ストレージアカウント名]
- パスワード:アクセスキー
ストレージアカウントの診断ログとは
ストレージアカウントのメトリック、つまりパフォーマンスのデータと操作ログを取得することができます。2023/3/15現在、診断設定(クラシック)と診断設定の2種類があります。
- 診断設定(クラシック):自身のBlob内の$logsコンテナ内にテキスト形式で以下を出力します。
- Blob/テーブル/キュー
- 操作ログ
- 読み取り
- 書き込み
- 削除
- 操作ログ
- Blob/ファイル/テーブル/キュー
- 7日間のメトリック
- 時間単位
- 分単位
- 7日間のメトリック
- Blob/テーブル/キュー
- 診断設定:Azure Monitorの機能で、クラシックよりもログの収集先の選択肢が増え、解析が容易になりました。
- ログ収集先
- LogAnalyticsワークスペースへの送信
- ストレージアカウントへの保存
- イベントハブへの送信
- Azureネイティブの外部ソフトウェアベンダサービスへ送信
- 収集可能なログの種類
- ストレージアカウント全般
- Transactionメトリック
- 各Blob/Azure Files/キュー/テーブル
- Transactionのメトリック
- 操作ログ
- 読み取り
- 書き込み
- 削除
- ストレージアカウント全般
- ログ収集先
Azure Filesの診断ログを設定する
ストレージアカウントの「file」の診断を有効化します。こちらの例では、LogAnalyticsワークスペースに送信します。
いざ、Azure Files共有の診断ログ確認
Azure Files共有に対しファイル新規作成、更新、削除などの操作をし、ログを記録します。
ログの操作
Azure Files共有に対する操作には2通りの方法があります。
Azureポータルからの操作
Azure Portalの[ファイル共有] > [対象の共有] > [Browse]からファイルアップロードやフォルダ削除などの操作を実行します。
クライアントPCからマウントしての操作
まず、クライアントPCから[ファイル共有] >[対象の共有]の[…] >「接続の認証方法」をストレージアカウントキーを選択します。
[Show Script]からマウントスクリプトを表示させて、右下の書類アイコンよりコピーし、Powershellを通常のユーザーで実行の上コピーした文字列をペーストします。
もしスクリプト1行目のTCP445疎通確認でNGの場合は下記が考えられます。
- インターネット経由はプロバイダ回線またはルータの設定によってTCP445が閉じている可能性があります
- ストレージアカウントのネットワークで「パブリックネットワークアクセス」が「選択した仮想ネットワークとIPアドレスから有効」もしくは「無効」になっている可能性があります
- 「無効」の場合は「選択した仮想ネットワークとIPアドレスから有効」に変更てください
- その上で、ファイアウォールに許可IPを追加するか、接続元をAzureVMからVNet経由にするなど場所を変えて実行してください
それぞれの操作に対するログの内容
Azureポータルからの操作
Azure Portalからの操作は診断ログの下記列に記録されます。
Protocol:HTTPS
AuthenticationType:AccountKey
uri:https://[ストレージアカウントのエンドポイント]:443/share?restype=share&sk=system-[n]
AuthenticationHash:system-[n](キーをハッシュ化した値)
system-[n]の部分が1もしくは2となり、アカウントキーのkey1、key2に該当し、どちらのキーを利用したか判明します。
クライアントPCからマウントしての操作
マウントの操作はログに以下列が各々記載されます。
Protocol:SMB
AuthenticationType:NTLMv2
uri:\\[ストレージアカウントのエンドポイント]\[マウントした共有]
AuthenticationHashが空でアカウントキーについては記録がされません。
終わりに
SRで確認いたしましたところ、マウントした共有フォルダについてはキーは確認ができないとのことです。
ログの内容より、Azure Filesをマウントした場合は認証方式がNTLMv2のため、キーを記録するのはHTTPSアクセスのみとなっている模様です。
Azure Files共有へどのアカウントがアクセスしたか確認をするには、Azure ADもしくはActive Directory認証の設定をし、ディレクトリ側でログ取得をすることが望ましいと考えられます。
また、闇雲に管理者権限でマウントをさせないために、Azure Portalでキーを取得するアカウントの権限を適切に管理することも必要になります。
熊田 沙代(日本ビジネスシステムズ株式会社)
かれこれサーバーエンジニア歴10数年。WindowsServer/Linux/OSS/vSphere/Hyper-Vと器用貧乏に経験し、現在はAzure IaaS/PaaSをメインとしたアーキテクトを担当してます。TEAM NACSのファンです。
担当記事一覧