アクセスレビュー手順

目的

GitLab のユーザーアクセスレビューは、内部および外部の IT 監査に必要な重要なコントロールアクティビティであり、脅威を最小化し、適切な人々が重要なシステムやインフラストラクチャに対する適切なアクセス権を持っていることを保証するのに役立ちます。この手順では、プロセスのステップを詳述し、アクセスレビューに関するコントロールオーナー向けのガイダンスを提供します。

組織への利益

• セキュリティリスクを低減する
• 休眠アカウントや無効化されたアカウントを特定する
• 必要なチームメンバーのみがシステムにアクセスできることを保証する
• ロールが変更されたユーザーが、もはや関連性のないアクセス権を保持していないことを検証する
• 退職したチームメンバーが会社のシステムにアクセスできなくなることを保証する
• 顧客の信頼を維持する GitLab のコンプライアンスおよび規制要件をサポートする

範囲

対象システム

セキュリティコンプライアンスは、要因のサブセットに基づいて対象システムのアクセスレビューを実施します。以下を含みます。

1. 起源: 外部認証への影響、Red Data System
2. 重要度: ミッションクリティカル
3. Lumos コネクタが利用可能な場合のビジネスクリティカル

• すべての GitLab システムとベンダー、および関連するクリティカルシステムティアの最新リストについては、テックスタックを参照してください。

対象外システム

上記の対象システム要因のしきい値の範囲外にあるシステム。一般的なベストプラクティスとして、すべてのシステムオーナーは、このプロセスをガイドとして使用し、自分が所有するシステムに対して少なくとも年次の退職者アクセスレビューを実施することを強く推奨されます。

役割と責任

Lumos とは何か、なぜ Okta タイルがあるのか？

Lumos は GitLab のユーザーアクセスレビューツールです。すべてのユーザーアクセスレビューを促進するために使用されます。デフォルトでは、すべてのチームメンバーはオンボーディング時に Lumos へのアクセス権を受け取ります。Lumos にアクセスするには、チームメンバーは Okta の Lumos タイルを選択できます。アクセスレビューが割り当てられた場合は、以下にリンクされているランブックに従ってアクセスレビューを完了してください。

アクセスレビュー手順

退職ユーザー

• システムの現在のアクセスリストは、GitLab のユーザーアクセスレビューツール Lumos を使用して、Workday（GitLab の雇用ステータスの真実の情報源）から派生したアクティブなチームメンバーのリストと突合されます。現在の GitLab チームメンバーではないアクティブなシステムアクセス権を持つユーザーが見つかった場合は、アクセス削除 Issue を起票してアクセスデプロビジョニングプロセスを開始します。

権限/特権アクセス

• システムへのアクセスは、GitLab のユーザーアクセスレビューツール Lumos のジョブロールと部門に基づいてレビューされます。アクセス権を持つユーザーベースのサイズと範囲に応じて、システムオーナーやマネージャーがユーザー権限のレビューに関与します。システムオーナーは、どのロール/部門が自分のシステムにアクセスすべきかについて詳細な知識を持っているはずです。Lumos を介したユーザーアクセスレビューの完了方法に関する詳細な手順については、こちらの Lumos レビューハンドブックページを参照してください。

アクセスレビューランブック

こちらの Lumos レビューハンドブックページは、これらのアクセスレビューを完了するためのアウトラインを提供しており、最小権限を確認する方法を含みます。

アクセスがもはや必要ないと特定された場合、もはやアクセスを必要としない各アカウントについてアクセス削除 Issue を起票し、システムアクセスレビュー Issue と関連付けます。

ご質問がある、またはアクセスレビューの完了でサポートが必要な場合は、GitLab セキュリティコンプライアンスチームにお問い合わせください。

アクセスレビューのケイデンス

アクセス削除

アクセスの適切性がレビューの一環として検証できない場合、またはシステムオーナー/レビュアーがユーザーを削除対象としてフラグ付けした場合、観察事項管理手順に従い、アクセス削除前にチームメンバーのマネージャーと検証が行われます。この検証は 7 暦日 以内に行われる必要があり、アクセスが必要ないと判断された場合 または その SLA 内にマネージャーとシステムオーナー/レビュアーの間で合意に達しない場合、アクセスは削除されます。検証されていないアクセスに関連するリスクが高すぎる場合、アクセスは即座に取り消され、影響を受けるユーザーは再プロビジョニングのために新しいアクセスリクエストプロセスへ案内されます。可能な限りアクセスの中断を避けたいですが、その中断の影響と、検証されていない GitLab システムへの継続アクセスのリスクとのバランスをとる必要があります。セキュリティコンプライアンスチームはアクセスを削除する責任を負わず、また削除する能力もありません。セキュリティコンプライアンスの役割と責任は、アクセス削除 Issue を起票し、それらの Issue を適切なシステムオーナーや IT 運用チームに割り当てることに限定されます。システムオーナーや IT 運用は、アクセス削除または調整の実行に責任を持ちます。影響を受けるチームメンバーへのアクセス削除または調整の連絡は、システムオーナー/レビュアーの裁量に委ねられます。

追加のガイダンス

アクセスレビューのタイミング

• アクセスレビューは、システムリストがエクスポートされてからレビューのすべてのステップが完了するまで 1 か月以内に完了することを目標としています。1 か月の時間枠内でアクセスレビューを完了することで、アクセスデータが古くなっていないことを保証します。アクセスレビューのコンポーネントが、開始された四半期内に完了しない場合、コンプライアンス目的でレビューは無効と見なされる可能性が高く、1 か月のタイムラインを遵守することがいっそう重要になります。

ルックバックレビュー

アクセスの削除（完全な削除または個別のロール/特権の削除）が必要なアカウントについては、ルックバックレビューが必要になる場合があります。ルックバックレビューは、アクセスが不適切だった期間のアクティビティのレビューです。

ルックバックが必要となる例のシナリオ:

• アクセスレビュー中に、退職したチームメンバーがシステム内でアクティブユーザーのままであることが特定された場合、アカウントが削除される前に GitLab はルックバックを実施し、退職したユーザーが最終日以降にアクセスを使用しなかったことを確認します。
• チームメンバーが、自身のロールには適切ではないがそのシステムへの何らかのレベルのアクセスを必要としていたシステムへの管理アクセスを持っていることが特定された場合、ルックバックを実施して管理アクセスが不適切に使用されなかったことを検証します。
• チームメンバーが、自身の職務責任と矛盾するロールをシステム内で持っており、他のシステムでのアクセスにより、確立されたコントロールポイントとプロセスを回避できる場合、ルックバックを実施してユーザーがアクセスを使用して確立されたプロセスとコントロールを回避しなかったことを検証します。

システムオーナーとマネージャーの間でルックバックが必要かどうかについて意見の相違がある場合、ルックバックを完了するべきです。 適切な担当者（通常はシステムオーナー）を関与させてルックバック評価を実施し、アカウントがアクセスを不適切に使用しなかったことを検証します。

すべてのケースでルックバックを実施する必要はないかもしれません。例えば:

• 人が矛盾しない部門間で異動し、移行中に以前のロールをサポートし続け、アクセスレビューが移行完了後にアクセスを削除する機会となる
• ロールが削除される。そのロールによって付与されたアクセスが、残る別のロールの一部として付与されるアクセスと重複しているため
• ユーザーがシステムへのアクセス権をもう使用していないが、そのアクセス権がユーザーが持っていてもリスクではなく、アクセスのニーズが再び生じた場合にアクセスリクエストを起票することで再付与できる
• 4 人のユーザーチームが同じシステムへの同じアクセス権を持っているが、利用は最小限である。ライセンスを解放し、最小権限の環境を維持するために、3 人のユーザーのアクセスが削除リクエストされる。

ユーザーのルックバックを実施する最もシンプルな方法は、彼らの最終ログイン日時をレビューし、アクセスが不適切でなかった日付以降ではなかったことを検証することです。最終ログインがアクセスが不適切になった後にアカウントが認証されたことを示している場合、その期間中にアカウントから何らかのアクティビティを判断し、リスクがないことを検証するために完全なレビューを実施する必要があります。最終ログインが利用できない場合、退職後にアカウントが不適切に使用されなかったことを確認するために、主要なトランザクションのレビューや類似のレビューを含む、他の検証を実施する必要があります。

完了したルックバックレビューの証拠は、アクセスレビューワークブックまたはその他の関連ドキュメント内に保持・記録される必要があります。

完了した変更の検証

変更や削除がリクエストされたアカウントについては、リクエストどおりに変更されたことの検証を完了し、その変更が成功したことの証拠を取得する必要があります。これはスクリーンショット、変更を反映した更新済みユーザーリスト、または類似の証拠で示すことができます。

アクセスレビュー通知リマインダー

監査証拠に必要なセキュリティコンプライアンス管理のアクセスレビューには、Lumos でのレビュー開始から 10 営業日の期限があります。期日からの日数に基づいて自動リマインダーが使用されます。

{-アクセスレビューが 10 日以内に完了しない場合、特定されたアクセスは削除されます。-}

レビュー対象のアクセスリスト

アクセスリスト生成

システムアクセスがどのように維持されるかに基づいて、アクセスレビューのためのアカウントと関連権限のエクスポート方法が決定されます。これは、ほとんどの場合、テックスタックアプリケーションで特定されたビジネスまたは技術オーナーの責任となります。

• インフラストラクチャが所有するシステムには、アクセスリストエクスポートリクエストのためにインフラストラクチャプロジェクトで Issue を起票する必要があります

アクセスリストデータフィールド

以下のフィールドは、徹底的なアクセスレビューを実施するのに役立つ最も包括的なものです（すべて役立ちますが、すべてが利用できるとは限りません）。

• アカウント名
• ユーザー名
• メールアドレス
• アクセス権限（アクセスレベル - ユーザー、管理者など）
• アカウント作成日タイムスタンプ
• 最終アクセス日タイムスタンプ

アクセスリスト生成検証

• リストの作成方法の証拠（データ取得日を含むべき）と共に、システム生成のアクセスリストを添付してください。タイムスタンプには、リストが取得された日、月、年を含める必要があります。
• リストの取得方法の証拠は、一般的にシステムインターフェース内のスクリーンショットの形をとります。スクリーンショットは、ユーザーリストを生成するためにシステム内で実行されたステップを記録します。
• リストを生成するためにクエリが使用された場合、クエリと共に、データを取得するために使用されたシステムのスクリーンショットを提供してください。例: PostgreSQL クエリウィンドウで、スクリーンショットがクエリが実行された日時と生のロー数を証拠として示すことを確認してください。これは母集団の網羅性を証拠として示すために使用されます。
• 網羅性と正確性を証拠として示すため、技術的に可能であれば、ロー数、ロー数のスクリーンショット、または生成されたファイルハッシュを含めてください。

デスクトップタイムスタンプスクリーンショットの提供方法

1. ワークステーションのシステムクロック（日付と時刻）がスクリーンショットに表示されていることを確認してください。

例外

この手順への例外は、情報セキュリティポリシー例外管理プロセスに従って追跡されます。

参照

• 識別と認証セキュリティコントロール
• アクセスリクエストハンドブックページ
• アクセス管理ポリシー

セキュリティアシュアランスホームページに戻る

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