アクセスリクエスト(AR)
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.アクセスリクエストは IT チームが所有し、オンボーディング、オフボーディング、内部異動リクエストは People Operations Team が所有します。
アクセスリクエストに関する質問がある場合は、Slack の Compass app(上部の検索バーに「Compass」と入力して見つけます)または [email protected] から私たちにお問い合わせください。
アクセスリクエストに関連するページ
はじめに
オープン中およびクローズ済みのすべての AR は access-requests project で確認でき、新しい Issue は こちら から作成できます。
新しい AR を作成する際には、リクエストを満たすためにどの追加情報が必要か、追加の承認が必要かを正確に把握できるよう、さまざまなテンプレートから選択するオプションが提示されます。 各 Issue タイプに必要なすべてのラベルを追加するようにしましたが、見落としがある可能性もあるため、送信前にリクエストを必ず再確認してください。
利用可能なテンプレートは多数ありますが、通常は以下のカテゴリのいずれかに分類されます。
利用可能なすべてのテンプレートの完全なリストは こちら にあります
個別または一括アクセスリクエスト
個別または一括アクセスリクエスト は、探している内容に他のテンプレートが一致しない場合に使用してください。
このテンプレートは、すべての人が同じシステムへのアクセスをリクエストしている限り、個人または複数人のアクセスをリクエストするために使用できます。複数人が異なるシステムへのアクセスを必要とする場合は、複数の Issue を作成してください。
アクセス変更リクエスト
アクセス変更リクエスト は、チームメンバーが現在プロビジョニングされているシステムへのアクセスを必要としなくなった場合、または同じレベルのアクセスを必要としなくなった場合(管理者からユーザーへのアクセス降格など)に記録されます。
追加情報については、GitLab ハンドブックの For Total Rewards Analysts: Processing Promotions & Compensation Changes セクションを参照してください。
Okta にはプロビジョニング/デプロビジョニングの自動化が導入されていますが、これはアクセスのプロビジョニングおよびデプロビジョニングを完全かつ正確に反映するものではない点に注意することが重要です。 Okta は、ユーザーのロール/グループに基づいて統合済み/実装済みのアプリケーションを割り当てるよう構成されています。 これにより、アプリケーションは Okta 経由でアクセス可能になりますが、ユーザーがシステムに直接アクセスできる可能性は残ります。 Okta に設定されているアプリケーションの一覧については、Okta Application Stack を参照してください。
アプリケーション固有のテンプレート
これらの Issue は、特定のアプリケーションおよびサービスへのアクセス、またはその内部でのアクセスに関連します。たとえば、1Password Request Form を使用して既存のボルトやグループを変更したり、新しいボルトやグループを作成したりできます。
管理者(Black)アカウント
私たちは Okta、1Password、Google Workspace など、さまざまなコアサービスへの管理者アクセスのプロビジョニングをサポートしています。このプロセスでは通常、まず新しいメールアドレスで管理者アカウントの作成をリクエストします。 管理者アカウントが作成されたら、特定のサービスへの管理者アクセスについて追加の AR を提出する必要があります。
名前変更リクエスト
希望する名前を変更したい場合は、このテンプレート を使用できます。その後、私たちは People Ops チームと協力して、すべてのシステムであなたの名前を更新し、新しいメールアドレスを提供します。
Baseline Entitlements
これらの Issue は、新規入社者に適切なアクセス権を割り当てるのに役立ちます。これらは多くのロールで自動的に作成され、通常は追加の承認を必要としません。ただし、自動化によって Issue が作成されない場合、新規入社者のマネージャーが手動で Issue を作成する責任を負います。
baseline Issue テンプレートの一覧は こちら にあり、自由にカスタマイズできます。
Baseline Entitlement Requests の作成時に追加のサポートが必要な場合は、Slack の Compass app(上部の検索バーに「Compass」と入力して見つけます)または [email protected] から私たちにお問い合わせください。
アクセスリクエストへの対応
部門アクセスリクエストボード
- 完全に自動化できるまでの間に追加ラベルが必要な場合やプロセス改善の提案がある場合は、Issue を作成 してください。
- AR は可能な場合、部門別に自動割り当ておよび自動ラベル付けされます。場合によっては、1 つのツールに複数のプロビジョナーがいます。テンプレートを自動割り当てできない場合、Business Technology は、プロビジョナーが自部門の Issue をラベル(例:
dept::to do)別にレビューできるボードを提供します。Issue を完了まで進める担当者のワークフロー管理は、各部門の責任です。 - Issue を 1 つの列から別の列に移動すると、最初のラベル(列ヘッダーに従う)が削除され、2 つ目のラベルが追加されます。列間で Issue を移動する際は注意してください。
- 各部門は、以下のボードを表示して未対応のアクセスリクエスト Issue を確認できます。
Tech Stack の新しい項目にアクセスリクエストプロセスを追加する
Tech Stack の新しい項目についてアクセスリクエストプロセスを開始する必要がある場合:
- ツールが tech stack に追加されていることを確認する
- チームメンバーが
provisionerdeprovisionerとして含まれていることを確認する - 関連するハンドブックページに、アクセスリクエスト提出の要件を文書化する
追加のヘルプ
- Issue で
@gitlab-com/gl-security/corp/helpdeskをメンションしてください。特定の SLA はありません。 - リクエストが緊急の場合は、Slack の Compass app(上部の検索バーに「Compass」と入力して見つけます)または [email protected] から私たちにお問い合わせください。
c955a93f)