リアルタイム不正検知 / リスクスコアリング(リスク管理)
取引イベントのストリーム監視・スコアリング・アラート
可用性 (SLA目標)
ストリーム処理のマネージドSLAに準拠(設計目標、構成に依存)
RTO(目標復旧時間)
ほぼ即時を目標(マネージドサービスの自動回復・再処理)
RPO(目標復旧時点)
ほぼ 0 を目標(イベントの永続化・リプレイ前提)
概算コスト
月 50,000〜300,000 円程度(イベント量・推論量に依存)
構成概要
- 可用性レベル
- サーバーレス
- コンピューティング
- Lambda
- 想定システム規模
- 中〜大規模(取引量に応じてスケール)
- コスト感
- ¥¥¥中コスト
使用AWSサービス
- Amazon Kinesis Data Streams(ストリーム取込)
- AWS Lambda
- Amazon SageMaker(ML推論 / 相当)
- Amazon DynamoDB
- Amazon EventBridge
- Amazon SNS
- Amazon S3
- Amazon Athena
- AWS Security Hub
- Amazon CloudWatch
- AWS KMS
概要
決済・口座・ログインなどの取引イベントをリアルタイムに監視し、不正検知・リスクスコアリングを行う構成です。取引イベントをストリーム(Kinesis 相当)で取り込み、Lambda が特徴量を生成、ML 推論エンドポイント(SageMaker 相当)でリスクスコアを算出します。スコアは DynamoDB に記録し、EventBridge のルールで閾値判定。高リスク取引は SNS でアラート通知し、後続の審査・ケース管理へ連携します。生イベントは S3 のデータレイクに保管し、Athena で事後分析・モデル改善に利用します。検知精度やレイテンシはモデル・特徴量・閾値・データ品質に依存します。
★ 設計のポイント
- ▸ストリーム取込 → 特徴量生成 → スコアリングのリアルタイムパイプライン
- ▸EventBridge のルールで閾値判定し、高リスクのみ通知・審査へ
- ▸S3 データレイク + Athena で事後分析とモデル改善のループを構成
- ▸イベントの永続化・リプレイにより見逃し・誤検知を是正可能
- ▸Security Hub / GuardDuty による脅威の集約(周辺・運用機能)
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
データ・分析
通知・連携
コピーしてすぐ使える IaC
リアルタイム不正検知 / リスクスコアリング(リスク管理)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as kinesis from "aws-cdk-lib/aws-kinesis";
import * as lambda from "aws-cdk-lib/aws-lambda";
import { KinesisEventSource } from "aws-cdk-lib/aws-lambda-event-sources";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as sns from "aws-cdk-lib/aws-sns";
import * as events from "aws-cdk-lib/aws-events";
import * as s3 from "aws-cdk-lib/aws-s3";
// ストリーム駆動:Kinesis → Lambda(特徴量/スコア) → DynamoDB、EventBridge→SNS、生イベントはS3。
// API Gateway は使いません(取引イベントのストリーム取込が入口)。
export class FraudDetectionStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const stream = new kinesis.Stream(this, "TxnStream", { shardCount: 2 });
const scores = new dynamodb.Table(this, "Scores", {
partitionKey: { name: "txnId", type: dynamodb.AttributeType.STRING },
billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
});
const lake = new s3.Bucket(this, "EventLake", {
encryption: s3.BucketEncryption.S3_MANAGED,
enforceSSL: true,
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
});
const alerts = new sns.Topic(this, "Alerts");
const bus = new events.EventBus(this, "RiskBus");
const scorer = new lambda.Function(this, "Scorer", {
runtime: lambda.Runtime.NODEJS_20_X,
handler: "index.handler",
code: lambda.Code.fromInline("exports.handler = async () => ({ ok: true });"),
environment: { SCORES: scores.tableName, LAKE: lake.bucketName, ALERTS: alerts.topicArn, BUS: bus.eventBusName },
});
scorer.addEventSource(new KinesisEventSource(stream, { batchSize: 100, startingPosition: lambda.StartingPosition.LATEST }));
scores.grantWriteData(scorer);
lake.grantWrite(scorer);
alerts.grantPublish(scorer);
// NOTE: SageMaker 推論エンドポイント呼び出し(sagemaker:InvokeEndpoint)を scorer のロールに付与します。
}
}この構成を選ぶ理由
リアルタイム不正検知 / リスクスコアリング(リスク管理)は、中〜大規模(取引量に応じてスケール)を想定し、運用負荷の低減とイベント駆動の伸縮性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
リスク管理で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 50,000〜300,000 円程度(イベント量・推論量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
リアルタイム不正検知 / リスクスコアリング(リスク管理)採用 | 中程度 | AWS標準運用で管理可能 | 需要に応じて高く伸縮 | クレジットカード / デビットのリアルタイム不正検知 |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
リスク管理
重要度
高(不正取引の検知遅延が直接的な損失に直結)
DR方式
サーバーレス・ストリームによる多AZ自動冗長(再処理可能な設計)
接続方式
行内チャネルからのイベント取込(内部連携 / ストリーミング)
データ分類
機密(取引・行動 / リスクスコア情報)
✔ データ活用・統制の設計目標
- •取引イベントの暗号化(転送時・保存時)と最小権限アクセスを設計目標とする
- •スコアリング結果・判定根拠を監査可能な形で保管する
- •イベントの再処理・リプレイを可能にし、見逃し・誤検知を是正する
- •Security Hub / GuardDuty による脅威の集約と相関分析
- •モデル更新・閾値変更の変更管理と職務分離
⚠ 前提条件・留意事項
- •検知精度・レイテンシは特徴量設計・モデル・閾値・データ品質に依存する
- •MLモデル(推論)の精度・公平性・説明可能性は別途の評価・監督を要する
- •記載の可用性・処理性能は設計目標であり、負荷・構成・テスト結果に依存する
✓ メリット
- •ストリーミングによる低遅延のリアルタイム検知(設計目標)
- •サーバーレス中心で取引量の変動に自動追従
- •S3 + Athena で事後分析とモデル改善のループを実現
- •イベント永続化により再処理・監査・是正が可能
✗ デメリット
- •検知精度・誤検知率はモデル・特徴量・閾値の継続改善に依存
- •MLモデルの精度・公平性・説明可能性の評価/監督が別途必要
- •イベント駆動・結果整合性を前提とした設計が必要
- •Kinesis / 推論など常時処理のコストが取引量に応じて増加
→ 主なユースケース
- •クレジットカード / デビットのリアルタイム不正検知
- •口座振替・送金のリスクスコアリングとアラート
- •ログイン・なりすまし検知(不正アクセス対策)