【ITニュース解説】DVC inventory should follow remotes and credential files

DVC（Data Version Control）は、大規模なデータファイルや機械学習モデルのバージョン管理を行うためのツールである。プログラミングコードの管理によく使われるGitと似ているが、DVCの大きな特徴は、データファイルそのものをGitリポジトリに直接保存するのではなく、データファイルの「メタデータ」と呼ばれる情報（ファイル名やハッシュ値など）だけをGitで管理する点にある。実際のデータ本体は、Amazon S3、Google Cloud Storage、Azure Blob Storageなどのクラウドストレージや、SSH、SFTP経由でアクセスするサーバー、あるいはローカルのディレクトリといった「リモート」と呼ばれる外部の保存先に格納される。この仕組みにより、巨大なデータを効率的に管理し、共有することが可能になる。

しかし、このDVCの運用方法は、セキュリティの観点から特別な注意を払う必要がある。DVCアプリケーションがインターネット上で見つかったとしても、それはデータが直接公開されていることを意味するわけではない。なぜなら、データ本体はリモートに保存されており、DVCアプリケーションはデータの場所を示す「目録」のような役割を果たすに過ぎないからだ。そのため、DVCを使ったシステムのセキュリティを確保する上で本当に重要なのは、どのようなリモートストレージが設定されているか、そしてそのリモートストレージにアクセスするための認証情報（パスワード、APIキー、秘密鍵など）がどのように管理されているか、という点になる。

最近の調査では、DVCアプリケーションの「指紋」を持つシステムがインターネット上で16件検出され、「DVC」という単語がタイトルに含まれるページが802件見つかった。しかし、これらの数字を「公開されたデータストアの数」と直接解釈するのは危険である。16件のアプリケーションは、実際のサービス、デモ、あるいは誤検出の可能性があり、802件のタイトルマッチにはDVCのドキュメント、チュートリアル、あるいは全く関係のない文脈での利用が含まれている可能性がある。これらの測定結果は、セキュリティ担当者がデータのリスクを評価し、具体的な調査を進めるための「手がかり」として利用すべきであり、直ちにデータ漏洩と判断すべきではない。

セキュリティにおけるDVCの重要な側面は、「リモート」自体が「信頼の境界」となることだ。DVCの公式ドキュメントにもあるように、リモートはデータやモデルを追跡・共有するための外部ストレージを指す。リモートへの認証情報やその他の設定は、dvc remote modifyコマンドを使って行われるが、ここで最も重要なのは、パスワードやAPIキーのような機密性の高い情報は、--localオプションを使用して.dvc/config.localというファイルに保存するべきであるという点だ。この.dvc/config.localファイルは、通常Gitのバージョン管理対象外（.gitignoreファイルで指定される）とされており、リポジトリにコミットされて他の開発者と共有されることはない。

もし誤って、認証情報のような機密性の高い情報を共有される.dvc/configファイルに書き込んでしまうと、そのリポジトリをクローンする全ての開発者がその認証情報を取得できてしまう危険性がある。また、CI/CD（継続的インテグレーション/継続的デリバリー）のビルドジョブが、認証情報をビルドの成果物やログファイルに誤って出力してしまった場合も、DVCアプリケーションが公開されていなくても、リモートストレージへのアクセス経路ができてしまう。したがって、ローカル設定ファイルに機密情報を適切に保護することが、DVCシステムにおけるデータセキュリティの最も重要な部分である。

DVCを利用するシステムのセキュリティ監査では、まず「データパスの棚卸し」から始めるべきだ。前述の16件のDVCアプリケーション検出結果や、組織内のDVCを使用しているリポジトリを特定する。各DVCプロジェクトについて、使用しているリモートのタイプ（S3、GCS、SSHなど）、そのURL、認証情報がどこから供給されているか（環境変数、ファイル、クラウドのIAMロールなど）、そして保存されているデータの分類（個人情報、企業秘密、公開データなど）を明確にする必要がある。さらに、リモートストレージ自体が一般公開されているか、バケットポリシーやSSHキーで適切に保護されているか、あるいは組織内のネットワークゲートウェイの内側にあるかといったアクセス制御の状態も確認すべきである。

ソースコードとして管理されているDVC設定ファイルと、Gitで無視されているローカル設定ファイルは、それぞれを独立してレビューすることが必須となる。特にCI/CDの定義を詳しく調査し、環境変数から認証情報を取得して使用するコマンドがないか、そしてその認証情報がビルドログに誤って出力されていないかを徹底的に確認する必要がある。S3のようなクラウドストレージをリモートとして使用している場合は、DVCの設定だけでなく、クラウドサービスプロバイダ側で設定されているIAM（Identity and Access Management）ポリシーやアクセスログも忘れずにレビューしなければならない。DVC側でどれだけ厳重な設定をしていても、S3バケット自体がパブリックアクセスを許可していれば、その設定は無効になってしまうからだ。

インターネット上で見つかったDVCアプリケーションやタイトルの一致件数は、あくまで調査の「手がかり」として活用すべきである。これらのマッチングが、実際にDVCを利用しているサービスなのか、あるいは単なるドキュメントページなのかを個別に検証し、そのプロジェクトの所有者を特定する必要がある。確認された各DVCプロジェクトについては、不正なユーザーがプライベートな設定やデータを読み取れないことをテストするべきだ。例えば、認証情報なしでdvc pullコマンドを試行し、リモートがアクセスを拒否することを確認する。また、Gitで無視されているはずのローカル設定ファイルが、誤ってバックアップ、コンテナイメージ、あるいはサポートバンドルに含まれてしまっていないかどうかも確認し、必要に応じて排除する措置をとる必要がある。

具体的なセキュリティ対策としては、認証情報はDVCで管理するコンテンツやGitリポジトリから完全に分離することが最も重要である。可能であれば、AWS STS（Security Token Service）の一時セキュリティ認証情報のようなクラウドサービスが提供する一時的な認証情報や、最小限の権限にスコープを限定したサービスアカウントを利用するべきだ。リモートストレージへのアクセスは、データアクセスが必要な最小限のネットワークとIDに厳しく制限し、ストレージサービス側でアクセスログを有効にして、不審なアクセスがないかを常に監視することも欠かせない。

万が一、認証情報が漏洩してしまった場合は、速やかにその認証情報を無効化または変更（ローテーション）し、漏洩が発覚する前のリモートアクセスログを徹底的にレビューする必要がある。DVCクライアントがインストールされていたかどうかだけでなく、どのオブジェクトが読み取られ、リスト表示され、変更されたのかという具体的な影響範囲を特定することが重要である。もしリモートストレージが匿名ユーザーによるリスト表示を許可している場合は、まずそのポリシーを修正することが最優先となる。

DVCは、その設定を通じてデータへの明確な経路を可視化するツールだ。セキュリティチームは、このデータ経路を追いかけ、どこにデータがあり、どのようにアクセスされているかを正確に把握する責任がある。インターネット上でのDVCアプリケーションの一致件数は、デプロイメントを発見する手助けにはなるものの、本当の意味での「データ資産の棚卸し」とは、使用されているリポジトリ、設定されているリモート、認証情報の出所、データの分類、そしてこれらのアクセス制御ポリシーが適切に設定されているかを検証した、具体的なリストなのである。