

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWSソースバージョン 2 の Security Lake クエリ (OCSF 1.1.0)
<a name="subscriber-query-examples2"></a>

次のセクションでは、Security Lake からのデータのクエリに関するガイダンスを提供し、AWSソースバージョン 2 でネイティブにサポートされているAWSソースのクエリ例をいくつか示します。これらのクエリは、特定の のデータを取得するように設計されていますAWS リージョン。これらの例では us-east-1 (米国東部 (バージニア北部)) を使用しています。さらに、サンプルクエリでは最大 25件のレコードを返す`LIMIT 25`パラメータを使用しています。このパラメーターは省略することも、好みに応じて調整することもできます。その他の例については、[Amazon Security Lake OCSF Queries GitHub ディレクトリ](https://github.com/awslabs/aws-security-analytics-bootstrap/tree/main/AWSSecurityAnalyticsBootstrap/amazon_security_lake_queries)を参照してください。

Security Lake がAWS Lake Formationデータベースとテーブルに保存するデータをクエリできます。Security Lake コンソール、API、またはAWS CLIでサードパーティのサブスクライバーを作成することもできます。サードパーティのサブスクライバーは、指定したソースから Lake Formation データをクエリすることもできます。

Lake Formation データレイク管理者は、データをクエリする IAM ID に、関連するデータベースとテーブルに対する`SELECT`権限を付与する必要があります。また、データをクエリする前に Security Lake にサブスクライバーを作成する必要があります。クエリ アクセスを持つサブスクライバを作成する方法の詳細については、「[Security Lake サブスクライバーのクエリアクセスの管理](subscriber-query-access.md)」を参照してください。

以下のクエリには、クエリが設定された保持設定内であることを確認する`eventDay`ために を使用する時間ベースのフィルターが含まれています。詳細については、「[Querying data with retention settings](subscriber-query-examples.md#security-lake-retention-setting-query-data)」を参照してください。

例えば、60 日以上経過したデータの有効期限が切れている場合、クエリには期限切れデータへのアクセスを防ぐための時間制約を含める必要があります。60 日間の保持期間については、クエリに次の句を含めます。

```
...
WHERE time_dt > DATE_ADD('day', -59, CURRENT_TIMESTAMP)
...
```

この句は、Amazon S3 と Apache Iceberg 間のデータや時間の重複を避けるために 59 日 (60 日ではなく) を使用します。

## ログソーステーブル
<a name="log-source-table"></a>

Security Lake データをクエリするときは、データが存在する Lake Formation テーブルの名前を含める必要があります。

```
SELECT *
FROM "amazon_security_lake_glue_db_DB_Region"."amazon_security_lake_table_DB_Region_SECURITY_LAKE_TABLE"
WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP
LIMIT 25
```

ログソーステーブルの一般的な値には次のようなものがあります。
+ `cloud_trail_mgmt_2_0` –AWS CloudTrail管理イベント
+ `lambda_execution_2_0`— Lambda CloudTrail データイベント
+ `s3_data_2_0` - S3 CloudTrail データイベント
+ `route53_2_0` - Amazon Route 53 Resolver クエリログ
+ `sh_findings_2_0` –AWS Security Hub CSPM検出結果
+ `vpc_flow_2_0` - Amazon Virtual Private Cloud (Amazon VPC) フローログ
+ `eks_audit_2_0` – Amazon Elastic Kubernetes Service (Amazon EKS) 監査ログ
+ `waf_2_0` –AWS WAF v2 ログ

**例: us-east-1 リージョン`sh_findings_2_0`からのテーブル内のすべての Security Hub CSPM 検出結果**

```
SELECT *
    FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_sh_findings_2_0"
    WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP
LIMIT 25
```

## データベースリージョン
<a name="database-region"></a>

Security Lake データをクエリするときは、データのクエリ元のデータベースリージョンの名前を含める必要があります。Security Lakeが現在利用可能なデータベースリージョンの全リストについては、「[Amazon Security Lake エンドポイント](https://docs.aws.amazon.com/general/latest/gr/securitylake.html)」を参照してください。

**例: ソース IP から Amazon Virtual Private Cloud アクティビティを一覧表示する**

次の例では、{{20230301}} ({{2023 年 3 月 1 日) 以降に記録されたソース IP 192.0.2.1}} からのすべての Amazon VPC アクティビティを、{{us-west-}}2 のテーブル {{vpc\_flow\_2\_0}} に一覧表示します`DB_Region`。

```
SELECT * 
    FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_vpc_flow_2_0"
    WHERE time_dt > TIMESTAMP '2023-03-01' 
    AND src_endpoint.ip = '192.0.2.1'
    ORDER BY time_dt desc
LIMIT 25
```

## パーティション日付
<a name="partition-date"></a>

データをパーティションすることで、各クエリによってスキャンされるデータの量を制限できるようになるため、パフォーマンスが向上し、コストが削減されます。Security Lake 2.0 では、Security Lake 1.0 とパーティションの動作が若干異なります。Security Lake は、`time_dt`、、`region`および によるパーティショニングを実装するようになりました`accountid`。一方、Security Lake 1.0 では、`eventDay`、、`region`および `accountid`パラメータによるパーティショニングを実装しました。

クエリ`time_dt`を実行すると、S3 から自動的に日付パーティションが生成され、Athena の任意の時間ベースのフィールドと同様にクエリを実行できます。

これは、2023 年 3 月 1 日以降に パーティションを使用して` time_dt`ログをクエリするクエリの例です。

```
SELECT *
    FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_vpc_flow_2_0"
WHERE time_dt > TIMESTAMP '2023-03-01'
AND src_endpoint.ip = '192.0.2.1'
ORDER BY time desc
LIMIT 25
```

`time_dt`の一般的な値は次の通りです。

**過去 1 年間に発生したイベント**  
`WHERE time_dt > CURRENT_TIMESTAMP - INTERVAL '1' YEAR`

**過去 1 か月に発生したイベント**  
`WHERE time_dt > CURRENT_TIMESTAMP - INTERVAL '1' MONTH`

**過去 30 日間に発生したイベント**  
`WHERE time_dt > CURRENT_TIMESTAMP - INTERVAL '30' DAY`

**過去 12 時間に発生したイベント**  
`WHERE time_dt > CURRENT_TIMESTAMP - INTERVAL '12' HOUR`

**過去 5 分間に発生したイベント**  
`WHERE time_dt > CURRENT_TIMESTAMP - INTERVAL '5' MINUTE`

**7 ～ 14 日前に発生したイベント**  
`WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '14' DAY AND CURRENT_TIMESTAMP - INTERVAL '7' DAY`

**特定の日付以降に発生するイベント**  
`WHERE time_dt >= TIMESTAMP '2023-03-01'`

**例:2023 年 3 月 1 日以降のソース IP`192.0.2.1` からのすべての CloudTrail アクティビティのリスト (表) `cloud_trail_mgmt_1_0`**

```
SELECT *
    FROM amazon_security_lake_glue_db_us_east_1.amazon_security_lake_table_us_east_1_cloud_trail_mgmt_1_0
    WHERE eventDay >= '{{20230301}}'
    AND src_endpoint.ip = '192.0.2.1'
    ORDER BY time desc
    LIMIT {{25}}
```

**例: テーブル `cloud_trail_mgmt_1_0` 内の過去 30 日間のソース IP `192.0.2.1` からのすべての CloudTrail アクティビティのリスト**

```
SELECT *
    FROM amazon_security_lake_glue_db_us_east_1.amazon_security_lake_table_us_east_1_cloud_trail_mgmt_1_0
    WHERE eventDay > cast(date_format(current_timestamp - INTERVAL '{{30}}' day, '%Y%m%d%H') as varchar) 
    AND src_endpoint.ip = '192.0.2.1'
    ORDER BY time desc
    LIMIT {{25 }}
```

## Security Lake オブザーバブルのクエリ
<a name="querying-observables-examples"></a>

オブザーバブルは、Security Lake 2.0 で利用可能になった新機能です。オブザーバブルオブジェクトは、イベントの多くの場所で見つかった関連情報を含むピボット要素です。オブザーバブルをクエリすると、ユーザーはデータセット全体で から高レベルのセキュリティインサイトを取得できます。

オブザーバブル内の特定の要素をクエリすることで、データセットを特定のユーザー名、リソース UIDs、IPs、ハッシュ、その他の IOC タイプ情報などに制限できます。

これは、observables 配列を使用して、IP 値 '172.01.02.03' を含む VPC フローと Route53 テーブル全体のログをクエリするクエリの例です。

```
WITH a AS 
    (SELECT 
    time_dt,
    observable.name,
    observable.value
    FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_vpc_flow_2_0",
    UNNEST(observables) AS t(observable)
    WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP
    AND observable.value='172.01.02.03'
    AND observable.name='src_endpoint.ip'),
b as 
    (SELECT 
    time_dt,
    observable.name,
    observable.value
    FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_route53_2_0",
    UNNEST(observables) AS t(observable)
    WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP
    AND observable.value='172.01.02.03'
    AND observable.name='src_endpoint.ip')
SELECT * FROM a
LEFT JOIN b ON a.value=b.value and a.name=b.name
LIMIT 25
```

## Amazon EKS 監査ログの Security Lake クエリの例
<a name="example-queries-eks-sourceversion2"></a>

Amazon EKS ログは、コントロールプレーンのアクティビティを追跡し、Amazon EKS コントロールプレーンからアカウントの CloudWatch Logs に直接監査ログと診断ログを提供します。これらのログを使用すると、クラスターの保護と実行が容易になります。サブスクライバーは EKS ログをクエリして、次のタイプの情報を学習できます。

AWSソースバージョン 2 の Amazon EKS 監査ログのクエリの例を次に示します。

**過去 7 日間の特定の URL へのリクエスト**

```
SELECT 
    time_dt,
    actor.user.name,
    http_request.url.path,
    activity_name
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_eks_audit_2_0" 
WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP 
AND activity_name = 'get'
and http_request.url.path = '/apis/coordination.k8s.io/v1/'
LIMIT 25
```

**過去 7 日間の「10.0.97.167」からリクエストを更新する**

```
SELECT 
    activity_name,
    time_dt,
    api.request,
    http_request.url.path,
    src_endpoint.ip,
    resources
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_eks_audit_2_0" 
WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP 
AND src_endpoint.ip = '10.0.97.167'
AND activity_name = 'Update'
LIMIT 25
```

**過去 7 日間のリソースkube-controller-manager」に関連するリクエストとレスポンス**

```
SELECT 
    activity_name,
    time_dt,
    api.request,
    api.response,
    resource.name
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_eks_audit_2_0",
UNNEST(resources) AS t(resource)
WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP 
AND resource.name = 'kube-controller-manager'
LIMIT 25
```