Note
Webhook は、特定のユース ケースの監査ログまたは API ポーリングの代替策として適している場合があります。 Webhook は、リポジトリ、Organization、または Enterprise で特定のイベントが発生したときに GitHub がサーバーに通知する方法です。 Enterprise、Organization、またはリポジトリで特定のイベントが発生したときに学習してログを記録するだけの場合、API や監査ログの検索と比較して、Webhook がより効率的である可能性があります。 「Webhook ドキュメント」をご覧ください。
監査ログのストリーミングについて
ストリーミングを使用して監査ログ データのコピーを保持することで、知的財産権を保護し、会社のコンプライアンスを維持できます。 監査ログでは、設定とアクセスの変更、ユーザー メンバーシップ、アプリのアクセス許可などのイベントが詳細に表示されます。 「エンタープライズの監査ログ イベント」、「組織の監査ログ イベント」、および「セキュリティ ログのイベント」を参照してください。
監査ログ データのストリーミングには、次の利点があります。
- データの探索。 大量のデータに対してクエリを実行するために、推奨されるツールを使用して、ストリーミングされたイベントを調べます。 ストリーミングには、Enterprise アカウント全体の監査イベントと Git イベントの両方が含まれます。
- データ保有。 エクスポートされた監査ログと Git イベント データを必要な期間だけ保持します。
ストリームをいつでも設定 または削除することができます。 ストリームは、ストリームが有効になった時点以降のアクティビティについて、企業内のすべての組織の監査イベントと Git イベント データをエクスポートします。
ストリーミングされたすべての監査ログは、圧縮された JSON ファイルとして送信されます。 ファイル名の形式は YYYY/MM/HH/MM/<uuid>.json.gz
です。
Note
GitHub は、最低1回の配信方法を使用します。 特定のネットワークまたはシステムの問題により、一部のイベントが重複する可能性があります。
監査ログ ストリーミングを有効にすると、お使いの GitHub Enterprise Server インスタンス のパフォーマンスに小さな影響を与える可能性があります。 このパフォーマンスへの影響を軽減するためにリソースを増やす方法の詳細については、「CPUあるいはメモリリソースの増加」を参照してください。
監査ログ ストリームの正常性のチェック
24 時間ごとに、正常性チェックが各ストリームに実行されます。 ストリームが正しく設定されていない場合、エンタープライズ所有者に電子メールが送信されます。 監査ログ イベントがストリームから削除されないようにするには、誤って構成されたストリームを 6 日以内に修正することが必要です。
ストリーミング構成を修正するには、「監査ログ ストリーミングの設定」の手順に従います。
監査ログのストリーミングの設定
監査ログ ストリームを設定するには、プロバイダーの指示に従います。
Amazon S3 へのストリーミングの設定
Note
S3 へのストリーミングが機能するためには、アプライアンスから Amazon リージョン us-east-1
にアクセスできる必要があります。
GitHub から監査ログのストリーミングを設定するには、次のものが必要です:
- AWS アクセス キー ID
- AWS 秘密鍵
アクセス キー ID と秘密鍵の作成またはアクセスについては、AWS ドキュメントの「Understanding and getting your AWS credentials」 (AWS 資格情報の理解と取得) を参照してください。
AWS から:
-
バケットを作成し、バケットへのパブリック アクセスをブロックします。 AWS ドキュメントの「Amazon S3 バケットの作成、設定、操作」をご覧ください。
-
GitHub によるバケットへの書き込みを許可するポリシーを作成します。 次の JSON をコピーし、
EXAMPLE-BUCKET
をバケットの名前に置き換えます。 GitHub では、この JSON のアクセス許可のみが必要になります。{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::EXAMPLE-BUCKET/*" } ] }
AWS ドキュメントの「IAM ポリシーの作成」をご覧ください。
GitHub から:
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[ストリームの構成] ドロップダウン メニューを選び、 [Amazon S3] をクリックします。
-
ストリームの設定を構成します。
- [バケット] に、ストリーミング先のバケットの名前を入力します。 たとえば、
auditlog-streaming-test
のようにします。 - [アクセス キー ID] に、アクセス キーの ID を入力します。 たとえば、
ABCAIOSFODNN7EXAMPLE1
のようにします。 - [シークレット キー] に、シークレット キーを入力します。 たとえば、
aBcJalrXUtnWXYZ/A1MDENG/zPxRfiCYEXAMPLEKEY
のようにします。
- [バケット] に、ストリーミング先のバケットの名前を入力します。 たとえば、
-
GitHub で Amazon S3 エンドポイントに接続して書き込めることを確認するには、 [Check endpoint](エンドポイントのチェック) をクリックします。
-
エンドポイントを正常に確認したら、 [保存] をクリックします。
AWS CloudTrail Lake との統合
S3 へのストリーミングと AWS CloudTrail Lake を統合することで、監査ログを統合できます。 AWS CloudTrail ドキュメントか、aws-samples/aws-cloudtrail-lake-github-audit-log
リポジトリの「GitHub 監査ログと CloudTrail オープン監査の統合」をご覧ください。
Azure Blob Storage へのストリーミングの設定
Note
Azure Government の Blob Storage への監査ログ ストリーミングはサポートされていません。
GitHub でのストリーミングを設定する前に、まず、Microsoft Azure でストレージ アカウントとコンテナーを作成してください。 Microsoft ドキュメントの「Azure Blob Storage の概要」を参照してください。
ストリームを構成するには、SAS トークンの URL が必要です。
Microsoft Azure portal から:
- [ホーム] ページで、 [ストレージ アカウント] をクリックします。
- [名前] で、使用するストレージ アカウントの名前をクリックします。
- [データ ストレージ] で、 [コンテナー] をクリックします。
- 使用するコンテナーの名前をクリックします。
- 左側のサイドバーの [設定] で、 [共有アクセス トークン] をクリックします。
- [アクセス許可] ドロップダウン メニューを選択し、
Create
とWrite
を選択して他のすべてのオプションの選択を解除します。 - シークレット ローテーション ポリシーに準拠する有効期限を設定します。
- [SAS トークンおよび URL を生成] をクリックします。
- 表示される BLOB SAS URL フィールドの値をコピーします。 この URL を GitHub で使用します。
GitHub から:
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[ストリームの構成] ドロップダウン メニューを選び、 [Azure Blob Storage] をクリックします。
-
構成ページで、Azure でコピーした BLOB SAS URL を入力します。 [Container] フィールドは、その URL に基づいて自動入力されます。
-
[Check endpoint] をクリックして、GitHub で Azure Blob Storage エンドポイントに接続して書き込むことができることを確認します。
-
エンドポイントを正常に確認したら、 [保存] をクリックします。
Azure Event Hubs へのストリーミングの設定
Note
Azure Government の Event Hubs インスタンスはサポートされていません。
GitHub のストリーミングを設定する前に、次のものが必要です:
- Microsoft Azure 内のイベント ハブ名前空間
- 名前空間内のイベント ハブ インスタンス (Microsoft ドキュメントの「クイック スタート: Azure portal を使用したイベント ハブの作成」を参照してください)
Microsoft Azure portal から:
- ページの上部にある検索ボックスを使用して、"Event Hubs" を検索します。
- [Event Hubs] を選択します。 イベント ハブの名前が一覧表示されます。
- ストリーミング先のイベント ハブの名前をメモします。 イベント ハブをクリックします。
- 左側のメニューで、 [共有アクセス ポリシー] を選びます。
- ポリシーの一覧から共有アクセス ポリシーを選ぶか、新しいポリシーを作成します。
- [接続文字列 -主キー] フィールドから接続文字列をコピーします。
GitHub から:
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[ストリームの構成] ドロップダウンを選び、[Azure Event Hubs] をクリックします。
-
構成ページで、次の項目を入力します:
- Azure Event Hubs インスタンスの名前。
- 接続文字列。
-
[Check endpoint] をクリックして、GitHub で Azure Events Hubs エンドポイントに接続して書き込むことができることを確認します。
-
エンドポイントを正常に確認したら、 [保存] をクリックします。
Datadog へのストリーミングの設定
Datadog へのストリーミングを設定するには、Datadog でクライアント トークンまたは API キーを作成し、次に認証用のトークンを使用して GitHub Enterprise Server で監査ログ ストリーミングを構成します。 Datadog でバケットやその他のストレージ コンテナーを作成する必要はありません。
Datadog へのストリーミングを設定した後は、「github.audit.streaming」でフィルター処理することで自分の監査ログ データを確認できます。 「ログの管理」を参照してください。
-
まだ Datadog アカウントがない場合は、それを作成します。
-
Datadog で、クライアント トークンまたは API キーを生成して、 [キーのコピー] をクリックします。 Datadog Docs の「API キーとアプリケーション キー」を参照してください。
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[ストリームの構成] ドロップダウンを選び、[Datadog] をクリックします。
-
[トークン] フィールドで、先ほどコピーしたトークンを貼り付けます。
-
[サイト] ドロップダウンを選び、Datadog サイトをクリックします。 ご利用のサイトを特定するには、その Datadog の URL を Datadog Docs にある Datadog サイト 内のテーブルと比較します。
-
GitHub で Datadog エンドポイントに接続して書き込みができることを確認するには、 [エンドポイントのチェック] をクリックします。
-
エンドポイントを正常に確認したら、 [保存] をクリックします。
-
数分後、Datadog の [ログ] タブに監査ログ データが表示されていることを確認します。 表示されない場合は、トークンとサイトが正しいことを GitHub で確認します。
Google Cloud Storage へのストリーミングの設定
Google Cloud Storage へのストリーミングを設定するには、適切な資格情報とアクセス許可を使用して、Google Cloud にサービス アカウントを作成し、そのサービス アカウントの資格情報を認証に使用して GitHub Enterprise Server での監査ログのストリーミングを構成します。
-
Google Cloud のサービス アカウントを作成します。 アカウントのアクセス制御または IAM ロールを設定する必要はありません。 Google Cloud ドキュメントの「サービス アカウントの作成と管理」を参照してください。
-
サービス アカウントの JSON キーを作成し、キーを安全に格納します。 Google Cloud ドキュメントの「サービス アカウント キーの作成と管理」を参照してください。
-
まだ作成していない場合は、バケットを作成します。 Google Cloud ドキュメントの「ストレージ バケットの作成」を参照してください。
-
バケットのストレージ オブジェクト作成者のロールをサービス アカウントに付与します。 Google Cloud ドキュメントの「クラウド IAM 権限を使用する」を参照してください。
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[ストリームの構成] ドロップダウンを選び、[Google Cloud Storage] をクリックします。
-
[Bucket] で、Google Cloud Storage バケットの名前を入力します。
-
[JSON Credentials] で、サービス アカウントの JSON キーのファイルの内容全体を貼り付けます。
-
GitHub で Google Cloud Storage バケットに接続して書き込めることを確認するには、 [Check endpoint] をクリックします。
-
エンドポイントを正常に確認したら、 [保存] をクリックします。
Splunk へのストリーミングの設定
監査ログを Splunk の HTTP Event Collector (HEC) エンドポイントにストリーミングするには、エンドポイントが HTTPS 接続を受け入れるように構成されていることを確認します。 Splunk ドキュメントの「Splunk Web で HTTP Event Collector を設定および作成する」を参照してください。
Note
GitHub では、<Domain>:port/services/collector
を使用して HEC エンドポイントを検証します。 エンドポイント (OpenTelemetry 経由の Splunk HEC Receiver など) をセルフホストする場合は、この目的地で到達できることを確認します。
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[ストリームの構成] ドロップダウンを選び、[Splunk] をクリックします。
-
構成ページで、次の項目を入力します:
-
ストリーミング先のアプリケーションがホストされているドメイン。
Splunk Cloud を使っている場合、
Domain
はhttp-inputs-<host>
である必要があります。ここで、host
は、Splunk Cloud で使うドメインです。 たとえば、「http-inputs-mycompany.splunkcloud.com
」のように入力します。無料試用版の Splunk Cloud を使っている場合、
Domain
はinputs.<host>
である必要があります。ここで、host
は、Splunk Cloud で使うドメインです。 たとえば、「inputs.mycompany.splunkcloud.com
」のようにします。 -
アプリケーションでデータを受け入れるポート。
Splunk Cloud を使用している場合は、
Port
を443
にする必要があります。無料試用版の Splunk Cloud を使っている場合、
Port
を8088
にしてください。 -
GitHub でサードパーティ アプリケーションに対する認証に使用できるトークン。
-
-
[Enable SSL verification] チェック ボックスはオンのままにします。
監査ログは常に、暗号化されたデータとしてストリーミングされます。ただし、このオプションを選択すると、GitHub によって、イベントの配信前に Splunk インスタンスの SSL 証明書が検証されます。 SSL 検証は、イベントが URL エンドポイントに安全に配信されることを保証するために役立ちます。 検証はオプションですが、SSL 検証は有効のままにすることをお勧めします。
-
[Check endpoint] をクリックして、GitHub で Splunk エンドポイントに接続して書き込むことができることを確認します。
-
エンドポイントを正常に確認したら、 [保存] をクリックします。
監査ログのストリーミングの削除
-
GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[ 設定] で、 [監査ログ] をクリックします。
-
[Audit log](監査ログ) の [Log streaming](ログ ストリーミング) をクリックします。
-
[危険なゾーン] の [ストリームの削除] をクリックします。
-
確認メッセージが表示されます。 [Delete stream] をクリックして確定します。