パブリッシャー向けの安全なプライベートアーティファクトリポジトリ

Secure Private Artifact Repositoryは、オペレーティングシステムのパッケージおよびPublisherコンテナイメージのNetskope管理ソースを、Netskope Private Access (NPA) Publisherに提供します。このソフトウェアをパブリックなUbuntuリポジトリやDocker Hubから直接取得するのではなく、対象となるパブリッシャーは、認証済みのNetskopeリポジトリのエンドポイントから取得します。

パッケージとコンテナイメージは、インストールまたは実行される前に暗号学的に検証されます。これにより、標準的なPublisherの展開およびアップグレードのエクスペリエンスを維持しながら、制御されたソフトウェア配信パスが提供されます。

メリットとユースケース

組織が以下を行う必要がある場合は、Secure Private Artifact Repositoryを使用してください：

• Strengthen software supply-chain controls. パブリッシャーは認証されたNetskopeエンドポイントからのソフトウェアを受け入れ、アーティファクトがNetskopeによって署名されていることを検証します。
• Reduce access to public software services. パブリックUbuntuリポジトリおよびDocker Hubへの直接的なPublisherアクセスを、目的別の2つのリポジトリエンドポイントに置き換えてください。
• Support regulated or restricted-egress environments. 簡潔なアウトバウンドファイアウォールポリシーを維持しつつ、Publisherソフトウェアには管理されたソースを使用してください。
• Simplify credential management. Netskopeは、リポジトリのクレデンシャルと署名キーをプロビジョニングおよび更新します。管理者は、リポジトリトークンや構成ファイルをPublisherにコピーしません。
• Improve control over distributed software. Netskopeは、特定されたパッケージバージョンまたはコンテナイメージダイジェストがPublisherに配布されるのを防ぐことができます。
• Reduce dependency on public registries and mirrors. Publisherの更新は、パブリックなUbuntuおよびDockerサービスの可用性、レート制限、保持ポリシーに直接依存しなくなります。

仕組み

Netskopeがテナントでこの機能を有効にした後：

1. Netskopeは、テナントスコープのリポジトリクレデンシャルと、アーティファクトの検証に使用される署名キーをプロビジョニングします。
2. Publisherは、既存のNPA管理パスを通じてクレデンシャルおよび検証資料を取得・更新します。このプロセスはNPAトンネルを使用します。
3. Publisherは、顧客ネットワークのアウトバウンドインターネット経由でソフトウェアを直接ダウンロードします
   • 接続：オペレーティングシステムのパッケージは npa-repository.netskope.com からダウンロードされます。
   • パブリッシャーコンテナイメージは npa-docker.netskope.com からダウンロードされます。
4. Ubuntu Publisherは、標準のAPT/GPGプロセスを通じてパッケージ署名を検証します。Publisherは、コンテナイメージを実行する前にイメージ署名を検証します。
5. 検証に失敗した場合、ソフトウェアはインストールまたは実行されません。Publisherは、署名されていないアーティファクトやパブリックリポジトリにフォールバックしません。

この機能は、Publisherソフトウェアのソースと検証方法を変更します。これにより、Publisherがプライベートアプリケーションのトラフィックを伝送する方法が変更されることはありません。

可用性とプラットフォームサポート

Secure Private Artifact Repositoryは、対象となるNPA ProおよびNPA Enterpriseテナントで利用可能です。Netskopeはテナントレベルでこの機能を有効にします。NetskopeテナントUIに顧客側で切り替え可能なトグルはありません。

Netskopeテクニカルアカウントマネージャー（TAM）またはNetskopeサポートに連絡し、利用資格と必要な最小Publisherバージョンを確認してください。

Publisherプラットフォーム	サポート
Ubuntu 22.04 以降	オペレーティングシステムのパッケージとPublisherのコンテナイメージは、セキュアなリポジトリを使用します。
RHEL 9.x	Publisherコンテナイメージは、セキュアなリポジトリを使用します。オペレーティングシステムのパッケージは、引き続き構成済みのRHELパッケージソースを使用します。
BWANプラットフォーム	サポートされていません。
中国地域のパブリッシャー	動作は確認されましたが、サポートされていません。個別のソフトウェア配信構成が適用されます。Netskopeの担当者とコンタクトを取ってください。

標準のPublisherのサイジングおよびディスク要件が引き続き適用されます。パブリッシャーの要件と推奨事項を参照してください。

ネットワーク要件

Publisherが以下の宛先へのアウトバウンド接続を行うことを許可します：

Destination	ポート	目的
npa-repository.netskope.com	TCP 443	オペレーティングシステムのパッケージ
npa-docker.netskope.com	TCP 443	パブリッシャーコンテナイメージ

リポジトリへのアクセスにインバウンドファイアウォールルールは不要です。

両方の宛先を、TLSインスペクション、SSLインターセプション、およびその他の接続書き換え制御の対象から除外してください。検査や書き換えを行うと、リポジトリの認証やアーティファクトの検証が妨げられ、更新が失敗する可能性があります。

この機能を有効にして検証した後は、Publisherのソフトウェア配信のためにUbuntu PublisherがパブリックUbuntuリポジトリやDocker Hubにアクセスする必要はなくなります。RHEL Publisherは、引き続き構成済みのオペレーティングシステムのパッケージソースへのアクセスを必要とします。

Secure Private Artifact Repositoryを有効にする

この機能は、Netskopeによってテナントごとに有効化されます。管理者は、個々のPublisher上でクレデンシャルのインストール、構成ファイルのコピー、またはリポジトリ構成コマンドの実行を行う必要はありません。

1. Publisherがサポートされているプラットフォームを使用していることを確認してください。
2. npa-repository.netskope.comおよびnpa-docker.netskope.comへのアウトバウンドTCP 443アクセスを許可します。
3. 両方のリポジトリエンドポイントを、TLS検査または接続書き換えの対象から除外してください。
4. 資格と有効化を評価するには、Netskope営業チームにコンタクトしてください。
5. NPAテナントで Secure Private Artifact Repository を有効にするよう依頼してください。
6. Netskopeの担当者から要求されたテナントおよびPublisherの情報を提供してください。
7. テナントが有効化され、パブリッシャーが最小バージョン要件を満たしていることの確認を待ってください。

有効化後、Publisherはリポジトリ構成を自動的に取得します。既存のPublisherは、次回の適用可能な更新またはアップグレードサイクル中に構成を適用します。有効化されたテナントに新しく展開されたPublisherは、通常のセットアップフローの一環として構成を取得します。

既存の手動または自動のパブリッシャー更新プロセスを引き続き使用できます。自動更新については、Configure Publisher Auto-Updatesを参照してください。

セキュアなリポジトリの検証

Netskopeが有効化を確認し、Publisherが構成を取得した後、以下を確認します：

• Repository connectivity: ファイアウォールまたはプロキシのログには、npa-repository.netskope.com および npa-docker.netskope.com へのアウトバウンドTLS接続が表示されます。
• Package source: Ubuntu Publisherでは、オペレーティングシステムの更新アクティビティにおいて、パブリックUbuntuリポジトリのアドレスではなくnpa-repository.netskope.comが使用されます。
• Container-image source: パブリッシャーイメージの更新アクティビティでは、Docker Hubの代わりに npa-docker.netskope.com を使用します。
• Update completion: 手動またはスケジュールされたPublisherの更新が正常に完了します。
• Private application access: リポジトリの移行中も、既存のPublisher接続とプライベートアプリケーションへのアクセスは正常に動作し続けます。

RHEL Publisherについては、コンテナイメージのソースのみを確認してください。RHELオペレーティングシステムのパッケージは、セキュアなプライベートアーティファクトリポジトリにリダイレクトされません。

検証が成功した後、パブリックなUbuntuおよびDockerの宛先が他の承認された目的で不要な場合は、それらへのPublisherアクセスを削除してください。

更新および障害時の動作

このリポジトリは、フェイルクローズするように設計されています：

Condition	Publisherの動作
パッケージ署名を検証できません	パッケージがインストールされておらず、パッケージ更新ステップが失敗します。
コンテナイメージの署名を検証できません	イメージは実行されず、Publisherイメージの更新は失敗します。
リポジトリのエンドポイントが一時的に利用できません	アップデートが延期または失敗した場合、接続が復旧した後に再試行できます。パブリッシャーはパブリックリポジトリにフォールバックしません。
リポジトリのクレデンシャルまたは署名キーの更新が必要です	Publisherは、NPA管理パスを通じて更新されたマテリアルを自動的に取得します。

リポジトリまたは検証の失敗は、ソフトウェアアップデートに影響します。これは、実行中のPublisherを介したプライベートアプリケーションのトラフィックには影響しません。

トラブルシューティング

パブリッシャーがセキュアなリポジトリを使用しない場合、またはアップデートが失敗した場合:

1. 両方のリポジトリエンドポイントが解決可能であり、かつTCP 443ポート経由でPublisherから到達可能であることを確認してください。
2. いずれのエンドポイントも、TLSインスペクション、SSLインターセプション、または接続の書き換えの対象になっていないことを確認してください。
3. PublisherがNetskopeに接続されたままであることを確認してください。これにより、NPA管理パスを通じてリポジトリのクレデンシャルと署名キーの更新を取得できます。
4. この機能が正しいテナントに対して有効になっていることを、Netskopeの担当者に確認してください。
5. Publisherがサポートされているプラットフォームで実行されており、かつ必要な最小Publisherバージョンを満たしていることを確認してください。
6. 接続の問題を解決してから、更新を再試行してください。

問題が解決しない場合は、パブリッシャーのログバンドルを収集し、Netskopeサポートにケースをオープンしてください。次が含まれます：

• 影響を受けるテナントおよびPublisher。
• Publisherのプラットフォームとバージョン。
• タイムゾーンを含む、障害発生のおおよその時刻。
• 障害がオペレーティングシステムのパッケージ、Publisherコンテナイメージ、またはリポジトリ構成のいずれに影響したか。
• 完全なエラーメッセージおよび関連するPublisherログ。

Publisherログの詳細については、「Publisher Logs for Troubleshooting」および「Collect Logs from a Publisher」を参照してください。

関連トピック

• 出版社管理
• パブリッシャーをデプロイする
• 出版社の要件と推奨事項
• パブリッシャーの自動更新を設定する
• トラブルシューティングのためのパブリッシャーログ