SAML IDプロバイダーとAWSのIAMロールを連携して、特定のサービスにのみアクセスできる


# 概要

社内のSAML IDプロバイダーとAWSを連携して、特定のサービスにだけアクセスできるようにする。前提として、[IAMに該当するSAML IDプロバイダーは作成ずみ](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_saml.html)とする。

流れとしては、以下の手順が必要となる。
1. IdP側でロールを作成する
2. IAM で SAML プロバイダーを作成する(今回はスキップ)
3. IAMでSAML用ロールを作成する
4. IdPソフトウェアを設定して、SAML信頼を確立する

# CDK
3. IAMでSAML用ロールを作成する
```ts
const role = new iam.Role(this, "MySamlRole", {
      roleName: "role name",
      description:
        "description",
      assumedBy: new iam.FederatedPrincipal(
        `arn:aws:iam::********:saml-provider/*********`, // 作成したSAMLプロバイダーのarnを指定
        {
          StringEquals: {
            "SAML:aud": "https://signin.aws.amazon.com/saml"
          }
        },
        "sts:AssumeRoleWithSAML"
      )
    });

    role.addManagedPolicy() // ←ここで任意の権限を付与
```

# 参考
- [SAML 2.0 フェデレーション用のロールの作成 (コンソール)](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html)
- あとはIdP側のドキュメント

SAML 2.0 フェデレーション用のIAMロールをCDKで作る


## 概要
SQSから呼び出した(=イベントソースにSQSを指定した)Lambda関数が、失敗しているにも関わらずLambdaに設定したDLQにメッセージが送信されていなかった。長らく原因がわからなずにいたが、AWSのサポートの方に教えてもらったのでメモしておく。

## 解説
SQSから呼び出した場合、Lambda関数は[同期呼び出し](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-sync.html)になる。LambdaのDLQは非同期呼び出しの際に有効な機能である。そのため、LambdaイベントソースマッピングにSQSを使用している関数ではLambdaがエラーになってもDLQにメッセージは送られない。

リトライは、SQS側で可視性タイムアウト後に(メッセージ保持期間の間は)自動的に行われるが、それでも失敗した場合はSQSに設定したDLQにメッセージが送られる。そのため、SQS→Lambdaの場合のアラートなどはSQS側のDLQを対象とする必要がある。

## 参考
- [非同期呼び出し - デッドレターキュー](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-async.html#invocation-dlq)
- [Amazon SQS での Lambda の使用](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-sqs.html)


SQSから呼び出したLambdaではDLQは使えない


# はじめに
ElasticBeanstalkのコンソールで説明(`Auto Scaling グループがオンデマンドベースインスタンスを超えてプロビジョニングする追加の容量の一部としてのオンデマンドインスタンスの割合。`)を見て意味がわからなかったのでメモ。

# 意味
「オンデマンドベース」で設定した台数以上のインスタンスを起動する際に、「ベースを超えるオンデマンド割合」に従って、[オンデマンドインスタンス](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)と[スポットインスタンス](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-spot-instances.html)を起動する。

例えば、「オンデマンドベース」が10で、「ベースを超えるオンデマンド割合」が75%だったら、11台目以降のインスタンスは75%がオンデマンドインスタンス、25%がスポットインスタンスになる。

# 参考
- https://pages.awscloud.com/rs/112-TZM-766/images/B1-01.pdf

EC2 Auto Scaling Groupのベースを超えるオンデマンド割合の意味

別のAWSアカウントで管理しているドメインのサブドメインを、別のアカウントのHosted Zoneに権限委譲する


## 概要
別のAWSアカウントで管理しているドメインのサブドメインを、別のAWSアカウントで使いたい。そんな時は、サブドメインを別のAWSアカウントのHosted Zoneに権限委譲すれば良い。それをCDKで行う手順をまとめる。

例として、以下のような状態を想定する。
- AWSアカウント1(ドメインを管理している)
  - masatora.com
- AWSアカウント2(委譲先)
  - stg.masatora.com←使いたいサブドメイン

## 手順とCDK
1. AWSアカウント2(委譲先)でホストゾーンを作成する
```ts
private createBuyerAJAVisionZone() {
    return new route53.PublicHostedZone(this, 'HostedZone', {
        zoneName: 'stg.masatora.com',
    })
}
```
2. 1で作成されたホストゾーンのNSレコードの値をコピー
3. AWSアカウント1(ドメインを管理している)でNSレコードを作成する
```ts
new route53.NsRecord(this, 'NsRecord', {
    zone: hostedZone,
    recordName: 'stg',
    values: [
    // ここに2でコピーしたNSレコードの値を入れる(4つある。追加も削除もせず全部入れることを推奨
    ],
})
```

## 参考
- ほぼこれを見ながらやった→[[Route 53] 別のAWSアカウントでサブドメインを使えるように権限移譲する](https://dev.classmethod.jp/articles/route53-transfer-hostedzones-2021/)
- [Amplifyのカスタムドメインの設定](https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/custom-domains.html)
    - 今回はAmplifyに設定したかったので。AmplifyではSSL/TLS証明書は自動発行・更新してくれる。
- https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/SOA-NSrecords.html

別のAWSアカウントでサブドメインを使う(CDK)

RDSの接続トラブルの原因を切り分ける手順をAWSの動画を参考にメモ


RDSにうまく接続できない時に考えられる原因と切り分け方のメモ。MySQLを例にする。MySQLのポートは3306と仮定する。

## (現象1) MySQLコマンドの結果が帰ってこないとき
別ターミナルで以下のコマンドを打つ。
```sh
netstat -an | grep 3306
```

### 結果パターン1
```sh
(略) SYN_SENT
```
上記のような出力の場合、リクエストを送ったがレスポンスが帰ってきていないことがわかる。その場合は、以下に問題がないか見直す。
1. セキュリティグループの設定
2. 接続元のFWの設定

## (現象2) Access Denied
→IDとパスワードが正しいことを確認する。

## (現象3) Unkown MySQL Server Host
→DNSの名前解決ができていない状態。この場合は、以下を確認する。
1. ホスト名が正しいか
2. 利用しているDNSが名前解決できる状態か(nslookup,dig,ncなどのコマンドを利用する)

## (現象4) 上記がすべて問題ないにも関わらず接続に失敗するとき
以下の可能性を確認する。
1. DBインスタンスのステータスが正常であること
2. 同時接続数の上限に達していないこと
3. DBのリソースが飽和していないこと

# 参考
- https://www.youtube.com/watch?v=_Ox2lul0cI8

RDSの接続トラブルの原因を切り分ける


## 概要

- SIEM on Amazon OpenSearchを利用して(仮想の)インシデント調査を行う社内のイベントに参加した。
- その際に勉強したことをメモしておく。


## 原因究明の流れ

1. 調査の目的を決める
2. ログを絞り込む
    
    <img src="https://i.gyazo.com/aaa955064105ab56dccbfe8140b6a32a.png" alt="drawing" width="600"/>
    
    - 画面上部: クエリーバー。ログをフィルターするための条件式を入力
    - 画面左: indexの切り替えとフィールド一覧表示
    - 画面右: 検索結果の時系列表示と、個々のログ。フィールドを指定してテーブル形式で表示することも可能
3. 対象のログの詳細を見て事象を理解する

## インシデント別捜査手順

### 1. IAM認証情報の侵害

- 調査の目的: `インシデントかどうかの判断と侵害の対象を特定する`
- **log-aws-guardduty-***のログに絞る
- フィールドを以下に絞る
    
    
    | @log_type | ログタイプまたはログを送信したサービス |
    | --- | --- |
    | rule.name | IDS 等の検出名。GuardDuty では Inspector や Macie の検出結果名 |
    | source.ip | 送信元 IP アドレス |
    | user.id | ユーザ固有の ID。AWS リソースの場合はアクセスキー |
    | user.name | ユーザ名。AWS リソースの場合は IAM のユーザー名やロール名。SH ログでは OS のユーザー名 |
    | cloud.instance.id | EC2 インスタンス ID |
    | rule.description | 検出した脅威の説明 |
- GuardDutyの検出結果のうち、IAMUserに関するものに絞る
    
    ```bash
    rule.name:*IAMUser*
    ```
    
- 侵害されたログの詳細のresorce.resourceTypeを見る
    
    <img src="https://i.gyazo.com/7eac4a690ae86caf87cf8ce8ef3b2de8.png" alt="drawing" width="600"/>
    
    - ↑から、**EC2 インスタンス (i-00bbd9925dcbc5bb9) にアタッチされているロール (threat-detection-wksp-compromised-ec2) の認証情報を窃取して攻撃したことがわかる**

### 2. EC2インスタンスの侵害

- 調査の目的: 侵入方法を調査して根本原因を特定する
- 攻撃内容を確認
    - **log-aws-guardduty-***のログに絞る
    - 以下で絞り込む
        
        ```bash
        rule.name:*EC2*
        ```
        
        <img src="https://i.gyazo.com/aaa955064105ab56dccbfe8140b6a32a.png" alt="drawing" width="600"/>
        
        - [rule.name](http://rule.name/) (findins) から SSH Brute Force と 脅威リストとのマッチング (MaliciousIPCaller.Custom) を確認
- SSHに対する脆弱性の有無を確認
    - **log-aws-securityhub-***のログに絞る
    - ↑のうち、event.module(ログの生成元)をinspectorに絞る
    - sshで検索
    - rule.descriptionで、検知されている脆弱性を確認
- SSH Brute Forceの攻撃の成否を確認
    - **log-linux-secure-**のログに絞る
    - sshdに対して外部からアクセスしているログを抽出
        
        ```bash
        process.name:sshd and source.ip:*
        ```
        
    - user.nameの値の集計を見ると、rootが大半(外部からの SSH 接続には一般的には使用されないユーザー名のため、攻撃と思われる)
        
        <img src="https://i.gyazo.com/834f2e80de61f85a19c4ae87f0240566.png" alt="drawing" width="600"/>
        
    - event.outcome(行為が成功したか失敗したか)が成功のログに絞り込む
        
        <img src="https://i.gyazo.com/5f5d659390f330748d42130f014e8967.png" alt="drawing" width="600"/>
        
    - ↑から、**SSH Brute Forceを行い、ユーザーID alice を使ってログインが成功したことがわかる**

### 3. S3バケットの侵害

- 調査の目的: `被害状況を確認する`
- 成功した攻撃を確認する
    - **log-aws-cloudtrail-***に絞る
    - 1で検出した攻撃者のuseridとipアドレスで絞り込む
    - event.outcomeで成功した攻撃に絞り込む
    - ログのrequestParameters.keyを見ると、config.pyを取得していることがわかる
        - requestParameters.keyを表示フィールドに追加すると、すべての攻撃でconfig.pyをGetしていることがわかる
            
            <img src="https://i.gyazo.com/8bdad1d77a57971f3fffad569b8ffb28.png" alt="drawing" width="600"/>
            
    - S3への驚異を検出するためMacieのログに絞り込む
        - **log-aws-securityhub-***を選んで、クエリーバーに `event.module:macie`
         と入力
        - ↑から、バケットに読み込み権限が付与されたことがわかる
    - PutBucketAclのログを探す
- 以下がわかる
    - **• 10:21:19 - S3 バケットに ACL を変更して読み込み権限を付与**
    - **• 10:24:03 - EC2 インスタンスの認証情報でS3 バケットから config.py を窃取**

## 感想

- GuardDutyがなければ調査の取っ掛かりすらつかめなかったはず。GuardDutyは絶対有効にしておこうと思った。

## 参考

- [SIEM on Amazon OpenSearch Service Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/60a6ee4e-e32d-42f5-bd9b-4a2f7c135a72/ja-JP/03-log-analysis-basics)
- [OpenSearch Dashboardsのクエリ(KQL)の書式](https://www.elastic.co/guide/en/kibana/current/kuery-query.html)
- [GuardDutyの検出結果の形式](https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-format.html)
- [GuardDutyの検出結果タイプ](https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html)

SIEM on Amazon OpenSearchでインシデント調査を行う


## はじめに
[AWSの認定資格、Solutions Architect - Associate(C03)を取得](https://www.credly.com/badges/77aa2bb9-b810-4dae-88e6-c539c7860be0)しました。
![画像](https://images.credly.com/size/680x680/images/0e284c3f-5164-4b21-8660-0d84737941bc/image.png)


## 試験対策
- 参考書
- BlackBelt視聴
- [Udemyの講座 『これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座』](https://www.udemy.com/course/aws-associate/learn/lecture/13377796?start=940)
- [Udemyの講座『AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）』](https://www.udemy.com/course/aws-knan/)の模擬試験解く

### 難易度について
ネット上の記事には、Udemyの模擬試験は本番よりややかんたん、という声もありました。が、自分の感触では本番の難易度はUdemyの講座『AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）』よりややかんたんか同じくらいに感じました。

## 終わりに
結構難しかったです。でも勉強になったので良かったです。


AWS Certified Solutions Architect - Associateを取得した


### バケットのサイズを確認する

```shell
aws s3 ls --summarize --human-readable --recursive s3://バケットのURL | grep Total
```


aws-cliでS3バケットの全ファイルサイズを確認する

GlueからAuroraのMySQLにJDBC接続する方法とハマったポイントについてまとめます


# 概要
AWS GlueからAuroraのMySQLにJDBC接続してデータを取得する方法を紹介します。

# 環境
- python==3.7
- pyspark==2.4.3

# 手順
1. VPCの設定
2. AWS Glue接続を追加する
3. コード

### VPCの設定
[こちら](https://docs.aws.amazon.com/ja_jp/glue/latest/dg/setup-vpc-for-glue-access.html)を参考に、接続したいAuroraクラスタが所属するセキュリティグループの設定をします。

### AWS Glue接続を追加する
[こちら](https://docs.aws.amazon.com/ja_jp/glue/latest/dg/console-connections.html)を参考に、接続したいAuroraクラスタに対して`AWS Glue`接続を追加します。

### コード
PySparkでJDBC接続する例を記載します。

```python
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session

jdbc_url = f"jdbc:mysql://{ホスト}:{ポート}/{データベース名}"

df = spark.read.jdbc(jdbc_url, {テーブル名}, properties={
                "user": {ユーザ名},
                "password": {パスワード}
            })
```

JDBCに接続するためのURLの形式は以下

```python
"jdbc:mysql://{ホスト}:{ポート}/{データベース名}"
```

# 参考
- [JDBC データストアに接続するための VPC の設定 AWS Glue](https://docs.aws.amazon.com/ja_jp/glue/latest/dg/setup-vpc-for-glue-access.html)
- [AWS Glue 接続の追加](https://docs.aws.amazon.com/ja_jp/glue/latest/dg/console-connections.html)
- [Sparkのドキュメント](https://spark.apache.org/docs/2.4.3/sql-data-sources-jdbc.html)

masatora.net