プロジェクトの可視性をパブリックまたはプライベートに変更する
Azure DevOps Services
この記事では、プロジェクトの可視性をパブリックまたはプライベートに変更する方法について説明します。
プライベート プロジェクトをパブリック表示に切り替えると、その内容はすべてパブリックになります。 特定のリポジトリ、エリア パス、またはビルド フォルダーをプライベートに選択的に保持することはできません。
セキュリティ
プライベート プロジェクトをパブリックに切り替えると、プロジェクト メンバーには次の変更が発生します。
- アクセス許可: Deny がマークされているアクセス許可が認識されません。 非メンバーには、任意のプロジェクト メンバーに割り当てることができる最小レベルの機能が自動的に付与されます。
- ビルド パイプライン: ビルド パイプラインが Project Collection スコープに設定されている場合は、代わりに Project スコープで実行されるため、悪意のあるユーザーがビルド サービスの認証トークンにアクセスするリスクが軽減されます。
- 利害関係者:
- リポジトリ: 利害関係者はパブリック プロジェクトでこれらの機能にフル アクセスできますが、プライベート プロジェクトではアクセス権がありません。
- ボード: 利害関係者はパブリック プロジェクトではフル アクセスできますが、プライベート プロジェクトでは部分的なアクセス権しか持っていません。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。
- Basic + Test Plans ユーザー: Basic + Test Plans ユーザーは、テスト プランからテストを表示および実行できます。 Basic ユーザーは、アクセス レベルを Basic + Test Plans にアップグレードして、テスト 計画を作成し、テスト ケースを追加する機能を含め、フル アクセスを取得できます。
アクセス
アクセスは、サインインしていないユーザー (匿名/パブリック ユーザー) とサインインしているがプロジェクトのメンバーではないユーザー (非プロジェクト メンバー) に制限されます。 非メンバーと呼ばれるユーザーの両方のカテゴリには、次の表に示すように、制限付きの読み取り専用アクセス権が付与されます。
| ハブ/設定 | 非メンバー アクセス | 利害関係者アクセス | 基本アクセス | 閲覧者アクセス | 共同作成者アクセス | プロジェクト管理者アクセス |
|---|---|---|---|---|---|---|
| ダッシュボード | 読み取り、+ 多数のウィジェットは使用できません | partial | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Wiki | 読み取り | フル | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Boards | 読み取り | partial | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Repos | 読み取り | フル | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| パイプライン | 読み取り | フル | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Test Plans | アクセスなし | アクセスなし | 部分アクセス | 読み取り | 読み取り/書き込み | read-write-administer |
| 通知 | アクセスなし | フル | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Search | フル | フル | フル | フル | フル | フル |
| 設定 | アクセスなし | フル | フル | 読み取り | 読み取り | read-write-administer |
前提条件
- Permissions: Project コレクション管理者グループのメンバーになる。 組織の所有者は、自動的にこのグループのメンバーになります。
- 組織: Azure DevOps 組織 があります。
- 認識:
- パブリック プロジェクトのアクセス レベルと利用できない機能について理解します。
- 部分的な移行オプションに注意してください。
- 移行チェックリストの項目を 確認します。
移行チェックリスト
ほとんどのプライベート プロジェクトには、大量の履歴データが含まれています。 古い作業項目、早期コミット、および以前のビルド パイプラインには、パブリックに共有したくない情報が含まれている場合があります。
次のチェックリストは、プロジェクトを公開する前に確認したい項目を示しています。 また、現在および将来のコンテンツのみを公開できるように、作業項目またはファイルを新しいプロジェクトに移行するためのヒントも提供します。
カテゴリ
ガイダンス
組織の ID と設定
ユーザーが次のリソースにアクセスし、organizationに関する詳細を取得することを理解します。
- ID: 各メンバーのorganizationとメール アドレスに追加されたすべてのメンバーの一覧。
- 設定: すべてのorganizationとプロジェクト設定の読み取り専用ビュー。
- プロセス メタデータ: organization内のすべてのプロジェクトのすべての選択リスト値。
- ビルドとリリース: それらをトリガーしたユーザーの名前と、Git コミットに埋め込まれたメール アドレスを含む ID。
- コミットと作業項目: 名、姓、電子メール アドレスなどの埋め込み情報。
プロジェクト間のオブジェクト リンク
プライベート プロジェクト内のリンクされた成果物の詳細がパブリック プロジェクト内に表示されるため、プロジェクト間にリンクが存在するかどうかを確認します。 ブランチ、ビルド、変更セット、コミット、ビルド内にあるコミット、ビルド、プル要求、バージョン管理された項目のリンクの種類を使用できます。 タイトルと名前は、バージョン管理された項目、ブランチ、Wiki ページ、pull request、および作業項目のリンクの種類で公開されます。
アジャイル ツールと作業項目
未公開のセキュリティ上の欠陥、資格情報、顧客データなど、作業項目が閉じられているものであっても、機密性の高い詳細が含まれていないことを確認します。 作業項目は、プライベート プロジェクトからパブリック プロジェクトに移行されたときに履歴を保持します。 すべてのディスカッションと説明を利用できます。 問題のある音声が含まれていないことを確認します。
どのエリア パスにも特別なロックダウン セキュリティ設定がないことを確認します。 拒否されたアクセス許可はパブリック プロジェクトでは適用されないため、制限された領域パスはパブリックになります。
"コード"
リポジトリの履歴に機密性の高い詳細がないことを確認します。パッチが適用されていないセキュリティバグ、資格情報、および配布する権利がないコード。
すべてのファイルの内容とコミット メッセージを使用できます。 問題のある音声が含まれていないことを確認します。 リポジトリ全体の公開に慣れていない場合は、ヒントを別のプロジェクトに移行できます。
詳細については、「 ヒント移行の手順」を参照してください。
ビルドとリリース
資格情報/シークレット、あいまいな URL、プライベート環境名など、どのパイプラインも機密データを公開していないことを確認します。
メンバー以外のユーザーがプライベート フィードへのアクセスを必要としないことを確認します。 ビルドは引き続きフィードにアクセスできますが、メンバー以外はアクセスできません。 ビルド パイプラインを新しいプロジェクトに移行する必要がある場合は、 YAML を使用してそれらをインポートおよびエクスポートできます。
テスト
パブリック プロジェクトのメンバー以外は、手動およびクラウドのロード テスト機能を使用できないことを理解してください。
分析とダッシュボード
一般向けのダッシュボードを構築することを検討してください。 一部の widget は、非メンバー 使用できません。
アイテム
プロジェクトのスコープが設定されているフィードのどのパッケージにもプライバシーに関する懸念がないことを確認します。 プロジェクトのスコープが設定されているフィード内のすべてのパッケージがパブリックになります。 プロジェクトのスコープが設定されているフィードの既存のアップストリーム設定はすべて、プロジェクトがパブリックになると無効になります。
拡張機能
プロジェクトのエクスペリエンスに不可欠な拡張機能があるかどうかを確認します。 たとえば、特定の方法でデータをレンダリングする作業項目フォームにコントロールがありますか? 重要な詳細を公開するカスタム拡張機能はありますか?
各拡張機能の作成者が、それをテストして非メンバーで使用できるようにしたことを確認します。
そうでない場合は、拡張機能の作成者に非メンバーのサポートを追加するよう依頼してください。
1. プロジェクトへの匿名アクセスを有効にする
プライベート プロジェクトをパブリック プロジェクトに変更する前に、次の手順を実行して、組織の匿名アクセスを有効にします。
組織にサインインします (
https://dev.azure.com/{yourorganization})。[組織の設定] を選択します。
![強調表示された [組織の設定] ボタンを示すスクリーンショット。](../../media/settings/open-admin-settings-vert.png?view=azure-devops)
Policiesを選択し、パブリック プロジェクトセキュリティ ポリシーを有効にします。
2. プロジェクトの可視性を設定する
プロジェクトにサインインします(
https://dev.azure.com/{Your_Oganization}{Your_Project})。プロジェクト設定>Overview> Visibility ドロップダウン メニューを選択し、Public または Private を選択し、保存をします。
パブリック プロジェクト用の制限付き UI 要素
次のユーザー インターフェイス要素は、非メンバーでは非表示です。
サービス
非表示の UI 要素
Boards
作業項目は使用できますが、バックログ、ボード、スプリント、クエリ、プランは非表示になります。
Repos
Team Foundation バージョン管理 (TFVC) リポジトリは非表示になっています。
Pipelines
ビルドとリリースは使用できますが、ライブラリ、タスク グループ、配置グループ、パッケージ、XAML ビルド システムは非表示になります。 ビルド パイプラインとリリース パイプラインのパイプラインエディターとタスク エディターは使用できません。 パブリック プレビュー段階の新しい [リリース] ページのみが使用できます。
Test Plans
Test Plansと、関連付けられている手動およびクラウドのロード テスト機能は非表示になります。
Analytics
Analytics ビューは非表示であり、非メンバーでは Analytics OData フィードはサポートされていません。 一般に、Power BI の統合はサポートされていません。
設定
設定と管理ページは非表示になります。
非メンバーは、次のタスクを実行できません。
- ファイル、作業項目、パイプラインなどの成果物を編集または作成します。
- お気に入りで、既存の成果物に従います。
- プロジェクト メンバーのメール アドレスとその他の連絡先情報を表示する。非メンバーは、名前と画像のみを表示できます。 また、ID で成果物の一覧をフィルター処理します。
- 同じ組織内の 2 つのパブリック プロジェクトを切り替えます。非メンバーは、URL を使用してパブリック プロジェクトにのみ直接移動できます。
- organization全体でコードまたは作業項目の検索を実行します。
パブリック プロジェクトに共同作成者を追加する
パブリック プロジェクトに投稿するには、メンバーとして追加され、利害関係者、基本、または基本 + テスト 計画のいずれかのアクセス権が割り当てられます。 詳細については、「アクセス レベルについて」を参照してください。
プロジェクト メンバー 追加 プライベート プロジェクトの場合と同じ方法で追加できます。 外部ユーザーを招待 の影響を理解していることを確認。 プロジェクトを作成した場合は、プロジェクト管理者グループに自動的に割り当てられます。
部分的な移行
組織に機密性の高い資料が含まれている場合は、パブリック プロジェクト ポリシーを有効にしないでください。 パブリック プロジェクトをホストするために、完全に別の組織を作成することをお勧めします。
作業項目をプライベート プロジェクトに移動する
機密性の高い作業項目がある場合は、別のプライベート プロジェクトに移動できます。 プロジェクト間リンクはメンバーに対して引き続き機能しますが、メンバー以外のユーザーは、プライベート プロジェクト内に存在するため、コンテンツにアクセスできません。
機密性の高い作業項目が多数ある場合は、現在のプロジェクトを非公開にすることを検討してください。 代わりに、別のorganizationで新しいパブリック プロジェクトを作成します。 作業項目の移行は、Microsoft が管理するオープンソース WiMigrator を使用して行うことができます。
Git ヒントのみを移行する
問題のある履歴のためにリポジトリを共有できない場合は、別のプロジェクトの新しいリポジトリへのヒントのみの移行を行うことを検討してください。 問題のあるリポジトリを含むプロジェクトをプライベートのままにします。 パブリックにしても構わないプロジェクトに新しいリポジトリを作成します。
警告
- 新しいリポジトリは古いリポジトリに接続されません。
- 今後、それらの間で変更を簡単に移行することはできません。
- pull request 履歴は移行されません。
Git ヒントのみを移行するには、次の手順を実行します。
- 既存のリポジトリを複製します:
git clone <clone_URL>。 - リポジトリのルート (
cd <reponame>) にいることを確認します。 - 開始するブランチの先端にあることを確認します:
git checkout main。 - Git データを削除します。Windows では
rmdir /s .git、macOS または Linux ではrm -rf .git。 - 新しい Git リポジトリ (
git init) を初期化します。 - パブリック プロジェクトに新しい空のリポジトリを作成します。
- 新しいリポジトリを配信元リモートとして追加します:
git remote add origin <new_clone_URL>。 - 新しいリポジトリをプッシュします:
git push --set-upstream origin main。