アクセスリクエスト（AR）

アクセスリクエストは IT チームが担当し、オンボーディング、オフボーディング、社内異動のリクエストは People Operations Team が担当します。

アクセスリクエストに関する質問がある場合は、Slack の Compass アプリ（上部の検索バーに「Compass」と入力して見つけます）または [email protected] へメールでお問い合わせください。

Lumos でアクセスをリクエストする

現在、ほとんどのアクセスリクエストは Issue を作成するのではなく、Lumos App Store で行います。Lumos はリクエストを Manager、システム所有者、およびその他の必要な承認者に自動的にルーティングし、自動化がある場合はアプリを自動的にプロビジョニングします。

アクセスリクエストを作成する

1. Okta タイルまたは Slack サイドバーから Lumos を開きます。
2. リストからアプリを選択します。
3. 次の情報を入力します。
   • アクセスを取得する人
   • 必要な権限
   • アクセス期間
   • ビジネス上の正当性 — アクセスが必要な「理由」

Slack から直接アクセスをリクエストすることもできます。Lumos アプリを見つけて Request Access をクリックし、アプリ、権限、対象ユーザーを選択します。すべての承認が完了しアクセスが付与されると、Lumos から通知されます。

リクエストのステータスを確認する

Lumos Slack アプリの Messages タブを開きます。作成したすべてのリクエストがそこに表示され、ステータスの変更に応じて動的に更新されます。

リクエストを承認する

Slack またはメールで通知を開くか、Okta タイルから Lumos にアクセスして、承認、コメント、または拒否します。Slack の承認画面で Edit をクリックすると、承認前にユーザーを追加するグループを変更できます。

まだすべてのアプリケーションが Lumos に含まれているわけではありません。プロビジョニング自動化とリクエスト量が多いアプリを優先し、Tech Stack をイテレーションごとに移行しています。必要なアプリが表示されない場合は、以下の Issue テンプレートを使用してください。

スクリーンショットと、アプリを Lumos App Store に追加するリクエスト方法を含む完全な手順については、Lumos Access Request Guideを参照してください。

アクセスリクエストに関連するページ

• よくある質問
• Tech Stack
• ベースライン権限
• 一時的なサービスプロバイダーのアクセスリクエストとオンボーディング

はじめに

すべてのオープンおよびクローズ済みの AR は access-requests プロジェクトで確認でき、新しい Issue はこちらから作成できます。

新しい AR を作成すると、リクエストを満たすために必要な追加情報と追加承認が必要かどうかを正確に判断するため、さまざまなテンプレートから選択できます。 Issue タイプごとに必要なラベルをすべて追加したことを確認していますが、見落としがある可能性もあるため、送信前にリクエストを必ず再確認してください

多数のテンプレートを利用できますが、通常は以下のいずれかのカテゴリに分類されます。

利用可能なすべてのテンプレートの完全な一覧はこちらで確認できます

個別または一括のアクセスリクエスト

Individual or Bulk Access Requests は、探している内容に他のテンプレートが一致しない場合に使用してください。

このテンプレートは、すべての人が同じシステムへのアクセスをリクエストしている場合に、個人または複数の人へのアクセスをリクエストするために使用できます。複数の人が異なるシステムへのアクセスを必要とする場合は、複数の Issue を作成してください。

アクセス変更リクエスト

Access Change Requests は、チームメンバーが現在プロビジョニング済みのシステムへのアクセスを必要としなくなった場合、または同じアクセスレベルを必要としなくなった場合（管理者からユーザーへのアクセスのダウングレードなど）に記録されます。 追加情報については、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 を送信する必要があります。

• Admin（Black）Account
• 1Password Admin
• AWS Admin
• Google Workspace Admin
• Okta Admin

氏名変更リクエスト

希望する名前を変更したい場合は、このテンプレートを使用できます。その後、People Ops チームと連携してすべてのシステムで名前を更新し、新しいメールアドレスを提供します。

ベースライン権限

これらの Issue は、新規採用者に適切なアクセスを割り当てるために役立ちます。多くのロールで自動的に作成され、通常は追加承認を必要としません。ただし、自動化で Issue が作成されない場合は、新規採用者の Manager が手動で Issue を作成する責任を負います。

ベースライン権限 Issue テンプレートの一覧はこちらで確認でき、自由にカスタマイズできます。

ベースライン権限リクエストの作成に関する追加サポートについては、Slack の Compass アプリ（上部の検索バーに「Compass」と入力して見つけます）または [email protected] へメールでお問い合わせください。

アクセスリクエストへの取り組み

部門のアクセスリクエストボード

• 完全に自動化できるまでの間に追加のラベルが必要な場合や、プロセス改善の提案がある場合は、Issue を作成してください。
• AR は可能な場合に部門別に自動割り当ておよび自動ラベル付けされます。場合によっては、ツールごとに複数のプロビジョニング担当者がいます。テンプレートを自動割り当てできない場合、Business Technology はプロビジョニング担当者がラベルごとに部門の Issue を確認できるボードを提供します（例：dept::to do）。Issue を完了まで担当する人のワークフロー管理は部門の責任です。
• Issue をある列から別の列へ移動すると、最初のラベル（列ヘッダーごと）が削除され、2 番目のラベルが追加されます。列間で Issue を移動する際は注意してください。
• 部門は以下のボードを表示して、未解決のアクセスリクエスト Issue を確認できます。

Tech Stack の新しい項目にアクセスリクエストプロセスを追加する

Tech Stack の新しい項目に対するアクセスリクエストプロセスを開始する必要がある場合：

1. ツールが Tech Stackに追加されていることを確認してください。
2. チームメンバーが provisioner deprovisioner として含まれていることを確認してください。
3. 関連するハンドブックページにアクセスリクエストを送信する要件を文書化してください。

追加のサポート

• 特定の SLA はありませんが、Issue で @gitlab-com/gl-security/corp/helpdesk に @メンションしてください。
• リクエストが緊急の場合は、Slack の Compass アプリ（上部の検索バーに「Compass」と入力して見つけます）または [email protected] へメールでお問い合わせください。

ページのソースコードを見る - ページの編集 - please contribute.