ソフトウェア開発プラットフォームのGitHubでは、作成したリポジトリを非公開にすることで関係者以外にコードを見られるのを防ぎつつ、プロジェクトを管理することができます。ところが、イスラエルのサイバーセキュリティ企業であるLassoの調査により、MicrosoftのAIアシスタント「Copilot」を通じて、Microsoftを含むさまざまな企業が管理する2万を超える非公開リポジトリにアクセス可能だったことが判明しました。
GitHubで非公開にされたはずのリポジトリがMicrosoftのAIアシスタント「Copilot」を通じて公開されていたという指摘 - GIGAZINE
その後Lassoは、「Bingがかつて公開されていた非公開GitHubリポジトリのインデックスを作成していたのなら、MicrosoftのCopilot経由でアクセスできるのではないか？」と考えて調査を行いました。
GitHubで非公開にされたはずのリポジトリがMicrosoftのAIアシスタント「Copilot」を通じて公開されていたという指摘 - GIGAZINE
その結果、Copilotはかつてリポジトリが公開されていた時点のデータを、ユーザーの要求に答える形で出力することがわかりました。Lassoの研究者らは、「GitHub上のあらゆるデータはたとえ一瞬しか公開されていない場合でもインデックス化され、Copilotのようなツールによって公開される可能性があると気付いた後、これらの情報にどれほど簡単にアクセスできるのかに衝撃を受けました」と述べています。
GitHubで非公開にされたはずのリポジトリがMicrosoftのAIアシスタント「Copilot」を通じて公開されていたという指摘 - GIGAZINE
Lassoは今回の調査結果から、「一度でもリポジトリを公開したら、すべてのデータが危険にさらされると仮定するべき」「大規模言語モデルを新たな脅威ベクトルとして認識するべき」「GitHubなどのプラットフォームでシークレットキーやトークンを公開しないなど基本的なデータ保護対策に努めるべき」といったアドバイスを送りました。
GitHubで非公開にされたはずのリポジトリがMicrosoftのAIアシスタント「Copilot」を通じて公開されていたという指摘 - GIGAZINE
⇧ Oh, my gosh...
「パブリックリポジトリ」を「プライベートリポジトリ」にしても「パブリックリポジトリ」だった時の状態のデータにはアクセスできてしまうのは衝撃ですな...
Lassoは2024年11月にこの調査結果をMicrosoftに通知したものの、Microsoftはこの問題について「影響が少ない」ものとして分類し、キャッシュの動作は許容可能だと主張したとのこと。
GitHubで非公開にされたはずのリポジトリがMicrosoftのAIアシスタント「Copilot」を通じて公開されていたという指摘 - GIGAZINE
Microsoftは2週間以内にBingキャッシュのリンク機能を削除し、問題を修正したように思われました。ところがその後も、Copilot経由でキャッシュされたページに引き続きアクセス可能であり、キャシュ自体から非公開リポジトリのデータが削除されたわけではないと報告されています。
GitHubで非公開にされたはずのリポジトリがMicrosoftのAIアシスタント「Copilot」を通じて公開されていたという指摘 - GIGAZINE
⇧「Microsoft」の回答も対応も杜撰過ぎる気がするんだが...
Azure Blob Storage でNFS 3.0対応していたのを知った話
職場の方に連携いただき、
Azure Blob Storage でのネットワーク ファイル システム (NFS) 3.0 プロトコル サポート
Blob Storage では、ネットワーク ファイル システム (NFS) 3.0 プロトコルがサポートされるようになりました。 このサポートにより、オブジェクト ストレージのスケールと価格で Linux ファイル システムの互換性が得られます。また、Linux クライアントは、Azure 仮想マシン (VM) またはオンプレミスのコンピューターから Blob Storage にコンテナーをマウントできます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support
⇧ という話を知りました。
ただし、
NFS 3.0 プロトコルのサポートでは、BLOB を階層型名前空間に編成する必要があります。 ストレージ アカウントを作成するときに、階層型名前空間を有効にできます。 階層型名前空間を使用する機能は、Azure Data Lake Storage によって導入されました。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support
これにより、コンピューター上のファイル システムを編成するのと同じ方法で、オブジェクト (ファイル) がディレクトリとサブディレクトリの階層に編成されます。 階層型名前空間は、スケールが線形で、データ容量もパフォーマンスも低下しません。 階層型名前空間からさまざまなプロトコルが拡張されます。 NFS 3.0 プロトコルは、これらの使用可能なプロトコルの 1 つです。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support
⇧「Azure Blob Storage」で「NFS 3.0」を利用するには、 制約があるらしく、
⇧ 上記の条件を満たした「ストレージアカウント」を作成する必要があるらしい。
Azure Filesでのディレクトリのマウントとの違いは？
で、気になってくるのは、「Azure Storage」サービスには様々な種類があるのだが、
⇧ 上記にあるように、「Azure Files」でも、「Azure Virtual Machine」のディレクトリに対してマウントが実現できますと。
「Phind」で違いを確認した感じでは、
| 機能 | Azure Blob Storage (NFS 3.0) | Azure Files |
|---|---|---|
| ストレージ構造 | ブロックBLOBベース
learn.microsoft.com
|
階層型ファイルシステム
intercept.cloud
|
| アクセスパターン | シーケンシャル読み取り向け
learn.microsoft.com
|
ランダムI/O向け
learn.microsoft.com
|
| スケーラビリティ | 最大5 PiB
learn.microsoft.com
|
最大100 TiB
learn.microsoft.com
|
| パフォーマンス | 最大20,000 IOPS、15 GiB/s
learn.microsoft.com
|
最大100,000 IOPS、10 GiB/s
learn.microsoft.com
|
| セキュリティ | VNetベースのネットワーク制御のみ
learn.microsoft.com
|
POSIXパーミッションとユーザー認証対応
learn.microsoft.com
|
| 主要ユースケース | HPC、メディア処理、大規模分析データ
learn.microsoft.com
|
共有ファイル、データベース、従来のアプリケーション
learn.microsoft.com
|
⇧ というような回答が返ってきた。
コストについて質問したところ、以下のような回答が返ってきた。
| 料金コンポーネント | Azure Blob Storage | Azure Files |
|---|---|---|
| ストレージ層 | • ホットストレージ（頻繁アクセス） • クールストレージ（時折アクセス） • アーカイブストレージ（まれにアクセス） intercept.cloud
|
• 標準層（Hot/Cool） • プレミアム層（高性能） learn.microsoft.com
|
| 最小容量要件 | なし
learn.microsoft.com
|
50 GiB
learn.microsoft.com
|
| 最大容量 | 5 PiB（単一ボリューム） 190.7 TiB（単一BLOB） learn.microsoft.com
|
100 TiB（単一共有） 4 TiB（単一ファイル） learn.microsoft.com
|
| パフォーマンス制限 | 最大20,000 IOPS、15 GiB/s
learn.microsoft.com
|
最大100,000 IOPS、10 GiB/s
learn.microsoft.com
|
| 冗長性オプション | LRS/ZRS/GZRS/GRS/RA-GRS
intercept.cloud
|
LRS/ZRS/GRS/GZRS
intercept.cloud
|
| 追加機能コスト | • HPCキャッシュ統合 • イミュータブルBLOB • メタデータインデックス learn.microsoft.com
|
• スナップショット • バックアップ • Azure File Sync learn.microsoft.com
|
具体的なコストを比較してもらったところ、以下のような回答が返ってきた。
| 使用パターン | Azure Blob Storage | Azure Files |
|---|---|---|
| 大規模データアーカイブ（100TB） | 約12万円/月（アーカイブ層、LRS） | 約250万円/月（標準層Hot、LRS） |
| 共有ファイルサーバー（1TB） | 約10万円/月（ホット層、LRS） | 約25万円/月（標準層Hot、LRS） |
| 開発環境（100GB） | 約1万円/月（ホット層、LRS） | 約250円/月（標準層Hot、LRS） |
なるほど、「AI」の回答が真実だと仮定した場合、余程、予算を潤沢に利用できるような企業でない限り、気軽に「Azure Files」を利用するのは躊躇してしまいますな...
Linux ファイル システムと BlobFuse2 の違い
何やら、「BlobFuse2」なるものが存在するらしいのだが、
BlobFuse とは - BlobFuse2
BlobFuse は Azure Blob Storage 用の仮想ファイル システム ドライバーです。 BlobFuse を使用して、Linux ファイル システムで既存の Azure ブロック BLOB データにアクセスします。 ページ BLOB はサポートされていません。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/blobfuse2-what-is
⇧ とあり、「Azure Storage」サービスに「仮想ファイルシステム」を提供するためのライブラリらしく、「Azure Storage」に特化したものらしい。
「NFS 3.0」との比較を「Phind」で質問してみたところ、以下のような回答が返ってきた。
| 機能 | BlobFuse2 | NFS 3.0 |
|---|---|---|
| アクセス方法 | REST API経由
learn.microsoft.com
|
NFSプロトコル（ポート111/2048）
learn.microsoft.com
|
| パフォーマンス | ローカルキャッシュによる高速アクセス
learn.microsoft.com
|
ネットワーク遅延の影響を受ける
bluexp.netapp.com
|
| セキュリティ | VNetとストレージアカウントキーによる認証
learn.microsoft.com
|
VNetベースのネットワーク制御のみ
learn.microsoft.com
|
| POSIX互換性 | 部分的にサポート（ハードリンク、特殊ファイル非対応）
learn.microsoft.com
|
完全なPOSIX互換性
learn.microsoft.com
|
| 大規模データ処理 | 並列ダウンロード/アップロード対応
learn.microsoft.com
|
シーケンシャルアクセス最適化
learn.microsoft.com
|
| ファイル操作制限 | 同時書き込みには制限あり
learn.microsoft.com
|
標準的なファイル操作をサポート
learn.microsoft.com
|
⇧「BlobFuse2」はパフォーマンス良いんかと思っていたところ、
制限事項
BlobFuse2 では、単に要求を BLOB REST API に変換するだけなので、BlobFuse2 によって 100% の POSIX 準拠は保証されません。 たとえば、名前変更操作は POSIX ではアトミックですが、BlobFuse2 では違います。
ネイティブ ファイル システムと BlobFuse2 の違いの完全な一覧を参照してください。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/blobfuse2-what-is#limitations
⇧ 落とし穴はありますと...
Linux ファイル システムと BlobFuse2 の違い
多くの点で、BlobFuse2 がマウントされたストレージは、ネイティブ Linux ファイル システムと同様に使用できます。 仮想ディレクトリ スキームは同じものであり、フォワードスラッシュ (/) が区切り記号として使用されます。 mkdir、opendir、readdir、rmdir、open、read、create、write、close、unlink、truncate、stat、rename などの基本的なファイル システム操作は、Linux ファイル システムと同じように機能します。
BlobFuse2 は、いくつかの重要な点で Linux ファイル システムとは異なります。
⇧「ストレージアカウント」の設定次第ってことなんかね？
相変わらず、「Microsoft」のドキュメントは分かり辛い...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
