この記事は秋の技術特集2024の2記事目です。
Okta のログは社内ユーザの認証とアクセスを記録するため、セキュリティとコンプライアンスの観点から長期保存を行いたいです。 AWS S3 に保存することでインシデント対応や不正アクセス調査に活用することができます。
Okta ログを保存したい
カケハシでの Okta
カケハシでは Okta を利用し、10種類以上のクラウドサービスへシングルサインオン（SSO） を行っています。
これにより以下の恩恵を受けています。
- ユーザ側 : ユーザーエクスペリエンスの向上
- 管理者側 : ユーザ管理の効率化
- セキュリティ : 認証機能の一元化
1ユーザとして、サービスごとにパスワード管理をしない世界はありがたいですね。
Okta ログの確認
認証基盤が Okta に集約された結果、認証ログとして Okta ログを長期保存しておきたくなります。
Oktaの ログは Okta Admin Console から確認することができます。
Okta ログには誰がどのサービスにログイン(SSO)したかの情報が残され、監査ログとして有効です。
- イベントタイプ:
user.authentication.sso
しかしコンソールからは90日までのログしか確認することがず、ログとして1箇所に集約して保存したいです。
そこで AWS S3 にログを保存しておくことにしました。
Okta ログを AWS S3 にログストリームで保存する
Okta にはログを外部サービスへログストリームする方法が用意されています。
対象には Amazon EventBridge と Splunk Cloud を選択でき、今回は Amazon EventBridge を利用し AWS S3 へ保存します。
全体構成としては以下となります。
- Okta -> EventBridge -> Data Firehose (旧Kinesis Firehose) -> S3
前提：スーパーアドミニストレーター権限が必要
Manage log streaming の項目には「Super Admin」のみ ● がついています。
ログストリーミングの設定には、スーパーアドミニストレーター権限が必要となります。
ただしスーパーアドミニストレーターは、組織のすべての管理タスクを実行できてしまうため、取り扱いには注意が必要です。
Okta 側の設定
Okta コンソール側からの設定です。
Oktaコンソールより Reports -> log streaming から設定します。
ドキュメント通りに進めると、追加したログストリームが［Active（アクティブ）］のステータスで［Log Streaming（ログストリーミング）］ページに表示されます（スクショを取り忘れました。。）。
AWS 側の設定
AWS コンソール側からの設定です。
Okta 側の設定が完了すると EventBridge コンソールからパートナーソースを確認できます。
同様に作成されていたカスタムイベントバス（aws.partner/okta.com/yourOktaSubdomain/yourAWSEventSourceName）と関連付けます。
イベントルールとして、以下のイベントパターンを定義しています。
{ "source": [{ "prefix": "aws.partner/okta.com" }] }
このルールに一致したイベントを Data Firehose へ送信し、S3 へ保存しています。
今回 AWS リソースの作成・管理は Terraform で行い、東京リージョンに作成しました。
まとめ
今回のブログでは、AWS S3へOktaログを保存する手順について解説しました。
Oktaはカケハシの認証基盤として重要な役割を果たしており、そのログにはサービスへのアクセス・認証情報が含まれています。そのため、Oktaが公式に提供しているログストリーミング機能を活用し、AWS S3のような信頼性の高いストレージにログを保存するこで、セキュリティインシデントの検出やコンプライアンス遵守を果たします。
設定が完了したら、Oktaスーパーアドミニストレーター権限の剥奪を忘れないようにしましょう。これは、最小権限の原則を適用し、セキュリティリスクを最小限に抑えるために重要です。
文責: 西山
