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は使えない


# はじめに
業務で新規アプリケーションの認可の設計・実装を行った。こういったものは新規開発じゃないとなかなか触れない部分で、忘れっちゃいそうなので、その際に勉強した認可・権限管理の基礎概念をまとめておく。

# 認可の概念
## 認可とはなにか

認可とは、「ユーザが何をできるか」をコントロールするプロセス。似ている概念として`認証`があるが、これは「ユーザが誰であるか」を確認するプロセスである。

## 認可の三大要素

認可のプロセスでは、「認可三大要素」をもとに認可の判断を下すことになる。「認可三大要素」は以下の3つである。
1. Subject(「誰が」リクエストしているか)
2. Object(「何に」しようとしているか)
3. Action(「何を」しようとしているか)

例えば、GitHubのようなソースコードの管理アプリケーションを想定すると、認可三大要素は以下のようになる。
- 誰が
  - ユーザ1が
- 何に
  - アプリケーションAのソースコードを
- 何を
  - 閲覧する

## 認可モデル

認可には、制御のメカニズムを表現するモデルが何種類か存在する。

1. RBAC
2. ReBAC
3. ABAC

<img src="https://assets-global.website-files.com/5f1483105c9a72fd0a3b662a/6093f4823b3749ec0a50afa5_TDy-IH54xrFUhzCHY-hpAvqFRTldduafw3uzMJJbq6oxrjkGagg-yU641eR053As3cSgiirDX-_PvVX8itjMV5C-OPVRHtVky8HW34FkEYaS1XqQCr13-sCpsjgrpE9KKCZOguZG.png" alt="drawing" width="300"/>

引用: https://www.osohq.com/academy/relationship-based-access-control-rebac

### RBAC
RBAC(アールバックと発音するらしい)は、人やグループに「ロール」を割り当て、そのロールに基づいて権限を制御するモデルである。例えば、「Admin」ロールを持つユーザのみ、重要なAPIにアクセスできる、などである。

### ReBAC
ReBACは、リソース間の「関係」に基づいて権限を制御するモデルである。例えば、フォルダへのアクセス権限を持つユーザは、フォルダ内のファイルへのアクセス権限を持つ、といったような制御ができる。RBACよりも柔軟な制御が可能になる。

### ABAC
ABACは、リソースの「属性」に基づいて権限を制御するモデルである。このモデルでは、実質的に無限の認可ロジックを適用することができる。例えば、isPublicがTrueのリソースには誰でもアクセスできる、業務時間外は機密ファイルにアクセスできない、といったような制御が可能になる。ReBACはABACの一種だと言うことができる。

# 認可のアプリケーションへの組み込み方

認可は、ユーザからすると正しく実装されて「当たり前」でありながら、バグがあると致命的な問題になりえる領域である。しかも、アプリケーションへの組み込み方をミスると簡単にバグや実装漏れが起きてしまう。にも関わらず、認可をどのようにアプリケーションに組み込むか、といった知見は(自分の印象では)あまり共有されていないように感じる。

## 何も考えずに組み込むとどうなるか

認可について意識しないままアプリケーションを実装していくと、以下のようにアプリケーションロジックと認可のロジックが混ざってしまいがちだと思う。
```go
if user.isAdmin {
    // アドミン向けの処理
} else {
    // その他のユーザ向けの処理
}

// 上記のようなロジックがソースコードの色んな場所に分散して存在する
```

上記のように、認可とアプリケーションロジックが分離できていないと、実装ミスが発生しやすく、変更容易性も低くなります。

## EnforceとDecision

ではどのようにアプリケーションに組み込むかというと、認可のロジックを一箇所に集約して、それを各所で呼び出すようにする。認可の用語では、認可の判定を下すことを`Decision`、その結果を適用することを`Enforecement`と呼ぶ。以下の画像のように、`Decision`は一箇所で集中管理してテストを厚く書き、アプリケーションの必要な箇所で`Enforcement`を行う。重要なのは、認可のロジックが一箇所にまとまっていることで、認可の適用はどこでやろうが何回やろうがかまわない。

<img src="https://assets-global.website-files.com/5f1483105c9a72fd0a3b662a/60516eaf35e59b6c28d3f34c_WFrzEd5ZWHDKF7jFh7Px7-0sPYCEMmosPJRKCeuy4QSjg9EoIfKGThEg-0OkBVFUZBELsirpT61LL1a57VyheldVOBH9BGBJ2c4cxJhcY2Hw6B4xkDjo34SQOLS9Nsz7QjYms6ZJ.png" alt="drawing" width="600"/>

引用: https://www.osohq.com/academy/what-is-authorization#addingauthzapp

### 認可を適用する箇所
認可を適用(`Enforcement`)する箇所にもパターンがある。
1. リクエストの入り口箇所
2. コントローラー層
3. DBへのアクセス箇所

個人的には、リクエストの入り口箇所で適用するのが良いと考えている(し、そういうアプリケーションが多いのではないだろうか？)。理由は、この層で認可の判定ができていれば、それ以降のアプリケーションコードでは権限について考えなくてすむためである。

また、APIのパス・メソッドは初期に定義してから頻繁に変更することは少ないため、安定して使うことができる。[Webアプリケーションフレームワークのミドルウェア](https://echo.labstack.com/docs/middleware/casbin-auth)で適用すれば、権限の適用漏れも防げる。

<img src="https://assets-global.website-files.com/5f1483105c9a72fd0a3b662a/6051515dfca17b4dac8d2162_eFvLwOry4DOBdqhLIyjwrPA1B3B9PMtu3m6b0iiBldsLUU-fsr8_xNcHOVqFQDkbvor_gQxlDPZ1x-F2L_-ypm2jFIfZuYMeK3PeTF9rJS96hU_FHZlQSC2TfJmnTGaJ5ON8i99b.png" alt="drawing" width="600"/>

引用: https://www.osohq.com/academy/what-is-authorization#addingauthzapp

## アーキテクチャパターン
ほとんどのアプリケーションでは、認可のロジックはアプリケーション内に実装することが望ましい。一方、巨大なサービスやマイクロサービスアーキテクチャを採用している場合は、認可専用のマイクロサービスを追加して認可のロジックを集中管理する。このアーキテクチャを採用しているのが、[GoogleのZanzibar](https://www.osohq.com/learn/google-zanzibar)である。

自分が開発したことがあるのは前者のみなので、ここらへんの詳細は[こちら](https://www.osohq.com/academy/what-is-authorization#addingauthzapp)を参照してください。

# 参考
- [Oso Authorization Academy](https://www.osohq.com/academy)
- [認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）](https://zenn.dev/she_techblog/articles/6eff1f28d107be?redirected=1)
- [アプリケーションにおける権限設計の課題](https://kenfdev.hateblo.jp/entry/2020/01/13/115032)
- [属性ベースのアクセス制御（ABAC）とは？ メリットと適切なアクセス制御モデル](https://www.okta.com/jp/blog/2020/09/attribute-based-access-control-abac/)


認可・権限管理の基礎概念


# はじめに
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のベースを超えるオンデマンド割合の意味

認可ライブラリCasbinでABACを実装してみる。


# はじめに
認可専用のライブラリである[Casbin](https://casbin.org/)を使って、[ABAC](https://en.wikipedia.org/wiki/Attribute-based_access_control)を実装してみる。Casbinでは、単純にルールを羅列するのではなく、[eval()という組み込み関数](https://casbin.org/ja/docs/abac#scaling-the-model-for-complex-and-large-numbers-of-abac-rules)を使用することで、任意の認可ロジックを簡潔に組み込むことができる。なお、CasbinそのものやRBAC/ABAC等の認可の概念に関する説明は本記事ではしない。

eval()では、[公式ドキュメントの例](https://casbin.org/ja/docs/abac/#scaling-the-model-for-complex-and-large-numbers-of-abac-rules)のように直接ロジックを渡すこともできるし、[`AddFunction`というAPI](https://casbin.org/ja/docs/management-api#addfunction)を使ってGoで記述した任意の関数を登録し、それをポリシー内で呼び出すこともできる。今回は後者の方法を使い、DBへのアクセスが必要な権限管理のロジック、という想定で実装してみる。

# 実装するシナリオ
今回は、病院で使用するシステムを想定し、「自分が担当している患者のデータにのみアクセスできる」という要件を実装する。

# 実装
## モデルの定義
`model.conf`ファイルにモデルを定義する。

```shell
[request_definition]
r = user, obj, method

[policy_definition]
p = path, method, rule

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = keyMatch5(r.obj.Path, p.path) && (r.method == p.method || p.method == "*") && eval(p.rule)
```

## ポリシー
`policy.csv`にポリシーを記述する。

```csv
p, /patient/{patient_id}/record, *, "is_assigned_patient(r.user.ID, r.obj.ID)"
```

## APIと認可用ミドルウェア
```go
package main

import (
	"fmt"
	"net/http"
	"strconv"

	"github.com/casbin/casbin/v2"
	"github.com/labstack/echo/v4"
)

var enforcer *casbin.Enforcer

func main() {
	e := echo.New()

	var err error
	enforcer, err = casbin.NewEnforcer("model.conf", "policy.csv")
	if err != nil {
		panic(err)
	}

	enforcer.EnableLog(true)

	// 任意の関数をCasbinに登録する
	enforcer.AddFunction("is_assigned_patient", func(args ...interface{}) (interface{}, error) {
		// NOTE: Casbinは文字列型のみ対応している https://github.com/casbin/casbin/issues/113
		doctorIDStr, ok := args[0].(string)
		if !ok {
			return false, fmt.Errorf("failed to get doctorID from casbin policy")
		}

		patientIDStr, ok := args[1].(string)
		if !ok {
			return false, fmt.Errorf("failed to get patientID from casbin policy")
		}

		doctorID, err := strconv.ParseUint(doctorIDStr, 10, 64)
		if err != nil {
			return false, fmt.Errorf("failed to parse doctorID: %w", err)
		}

		patientID, err := strconv.ParseUint(patientIDStr, 10, 64)
		if err != nil {
			return false, fmt.Errorf("failed to parse patientID: %w", err)
		}

        // DBから、リクエストを送った医者が担当している患者かどうかを取得する(今回はモック)
		return isPatientAssignedToDoctor(int(doctorID), int(patientID)), nil
	})

	e.Use(authorize)
	e.GET("/patient/:patient_id/record", func(c echo.Context) error {
		return c.String(http.StatusOK, "Access Allowed\n\n")
	})
	e.Logger.Fatal(e.Start(":1323"))
}

type User struct {
	ID int
}

type Object struct {
	ID   int
	Path string
}

// 認可をミドルウェアで実施する
func authorize(next echo.HandlerFunc) echo.HandlerFunc {
	return func(c echo.Context) error {
		path := c.Request().URL.Path
		method := c.Request().Method

		userIDStr := c.QueryParam("user_id")
		userID, err := strconv.Atoi(userIDStr)
		if err != nil {
			return echo.NewHTTPError(http.StatusBadRequest, err.Error())
		}

		objectIDStr := c.Param("patient_id")
		objectID, err := strconv.Atoi(objectIDStr)
		if err != nil {
			return echo.NewHTTPError(http.StatusBadRequest, err.Error())
		}

		obj := Object{ID: objectID, Path: path}

		ok, err := enforcer.Enforce(User{ID: userID}, obj, method)
		if err != nil {
			return echo.NewHTTPError(http.StatusInternalServerError, err.Error())
		}
		if ok {
			return next(c)
		}
		return c.String(http.StatusForbidden, "Access denied\n\n")
	}
}

func isPatientAssignedToDoctor(doctorID int, patientID int) bool {
	if doctorID == 1 && patientID == 1 {
		return true
	}
	return false
}
```

注意点として、[CasbinのポリシーはString型にしか対応していない](https://github.com/casbin/casbin/issues/113)。文字列型以外を渡すと正しく判定できないことがあるので注意が必要。

# 動作確認
```shell
// 自分が担当している患者の情報は取得できる
$ curl 'http://localhost:1323/patient/1/record?user_id=1'
Access Allowed

// 自分が担当していない患者の情報は取得できない
$ curl 'http://localhost:1323/patient/2/record?user_id=1'
Access denied
```

# 参考文献
- https://casbin.org/ja/docs/abac
- https://future-architect.github.io/articles/20221004a/

GolangとCasbinでABACを実装する

Goのforループで同一アドレスに値が格納される挙動と、それがクロージャに与える影響についての概要と解決策


# 3行で
- Golang1.21まででは、ループ変数は同じアドレスに値が格納される。
- そのため、ループ内でクロージャを定義して呼び出す等の特定のケースで、全てのループで毎回同じ値になることがある。
- これは、ループ内で変数を定義し直すのが1.21までの標準的な解決策。[1.22で修正される予定](https://github.com/golang/go/wiki/LoopvarExperiment)らしい。[1.21でもexperimentalで使える](https://github.com/golang/go/discussions/56010)。

# Go1.21までの仕様と発生しうる問題
以下のコード例で、iの値とアドレスが表示されるが、Go1.21までの挙動では全てのイテレーションでiのアドレスが同じである。これがクロージャを使用した際に問題を引き起こす。

```go
package main

import "fmt"

func main() {
    for i := 0; i < 3; i++ {
        fmt.Printf("iの値: %d, iのアドレス: %p\n", i, &i)
    }
}
```
https://go.dev/play/p/5X09tR5MNec

```shell
iの値: 0, iのアドレス: 0xc000012028
iの値: 1, iのアドレス: 0xc000012028
iの値: 2, iのアドレス: 0xc000012028

Program exited.
```

そのため、ループ内でクロージャを定義して呼び出す等のケースでは、全てのループで毎回同じ値になってしまう。これは気づきにくいバグの原因になりがちだと思う。

```go
package main

import "fmt"

func main() {
	var funcs []func()

	for i := 0; i < 3; i++ {
		funcs = append(funcs, func() {
			fmt.Println(i)
		})
	}

	for _, f := range funcs {
		f()
	}
}
```
https://go.dev/play/p/hn-5RCih2yP

```shell
3
3
3

Program exited.
```

# その他同様の問題が発生しうるケース
クロージャだけでなく、goroutineやt.parallelを使用する場合にも同様の問題が生じ得る。これらの状況でも変数のスコープには注意が必要である。

# 対応策
この問題[Goのバージョン1.22で修正されることが予定](https://github.com/golang/go/wiki/LoopvarExperiment)されている。それまでは、イテレーションごとにループ変数をローカル変数に代入し直すことで問題を解決できる。

```go
package main

import "fmt"

func main() {
	var funcs []func()

	for i := 0; i < 3; i++ {
		i := i // ここで i のコピーを作成する
		funcs = append(funcs, func() {
			fmt.Println(i)
		})
	}

	for _, f := range funcs {
		f()
	}
}
```
https://go.dev/play/p/JSWkYlucoZs


```shell
0
1
2

Program exited.
```

# 参考
- [【Go 1.21】ループ変数が共有される問題への対策（プレビュー）が公開されました](https://moneyforward-dev.jp/entry/2023/08/15/150000)
- [Go Wiki LoopvarExperiment](https://github.com/golang/go/wiki/LoopvarExperiment)

Golangのループ内でクロージャを定義して使用する場合の注意点

ACID/トランザクション分離レベルといった概念の備忘録と、MySQLで実装する際に何を気をつけるべきかの整理


# 概要
トランザクション分離レベルの概念を整理した上で、MySQLを使ってアプリケーションを実装する際に意識するべき点をまとめます。

# 前提知識
## トランザクション
トランザクションは、アプリケーションにおいて、複数の読み書き操作を論理的な単位でまとめる方法です。トランザクションは完全に実行される(commit)か、あるいは全く実行されないか(rollback)のどちらかとなります。

## ACID特性
ACIDは、トランザクションに求められる4つの要素を指します。各データベースのACIDの実装はかなり異なるらしいです。

1. 原子性(Atomicity): エラーが発生した際にトランザクションを中断し、そのトランザクションのすべての書き込みを破棄できる
2. 一貫性(Consistency): トランザクションの開始時と終了時でデータが一貫性のある状態になっている
3. 分離性(Isolation): 進行中のトランザクションは他のトランザクションの途中の操作に影響されず、独立して実行される
4. 永続性(Durability): トランザクションのコミットが成功した場合、そのトランザクションで書き込まれたデータが失われない(ハードウェア障害やデータベースがクラッシュしたとしても)

## トランザクション分離レベル(弱いトランザクションの分離)
ほとんどのデータベースでは、単一のオブジェクトの原子性や分離性を保証します。問題となるのは、複数のトランザクションが同時に一つのデータを変更しようとしたり、一つのトランザクションが他のトランザクションによって変更されたデータを読み取ろうとする時です。

この問題を回避するための理想的な方法は、直列化可能な分離性（Serializable）を採用することです。これは、トランザクションが順番に（直列的に）実行され、その結果が同じになることを保証します。しかし、パフォーマンスの観点から、多くのデータベースでは「弱いレベルの分離性」を採用しています。

この「弱いレベルの分離性」とは、すべての並行性の問題を回避するのではなく、特定の問題に対する保護のみを提供するものです。具体的には、以下のレベルが存在します：

1. Read Uncommitted
2. Read Committed
3. Repeatable Read

### Read Uncommitted
最も弱いトランザクション分離レベルで、他のトランザクションがまだコミットしていない変更を読み取ることが許されます。

### Read Committed
このレベルでは、以下の2つを保証します。
1. ダーティリードは生じない(コミットされたデータのみ読み取り可能)
2. ダーティライトは生じない(コミットされたデータに対してのみ上書き可能)

一方で、読み取りスキューやファントムリードという問題が生じる可能性があります。

### Repeatable Read
それぞれのトランザクションがデータベースの一貫性のあるスナップショットからのみ読み取りを行います。すなわち、トランザクションが読み取るデータは、そのトランザクションの開始時点でコミット済みのものだけで、トランザクションの実行途中で別のトランザクションによってコミットされたデータは反映されません。

それにより、Read Committedでは生じる読み取りスキューやファントムリードといった問題を回避できます。

## MySQL(InnoDB)におけるトランザクション分離レベル
[デフォルトで、MySQL(InnoDB)はRepeatable Readを採用](https://dev.mysql.com/doc/refman/8.0/ja/innodb-transaction-isolation-levels.html)しています。ただし、MySQL(InnoDB)のRepeatable Readは更新のロストを自動検出しないらしい。

# 起きうる問題と対応方法
MySQL(InnoDB)のRepeatable Readの実装において起きうる問題は以下です。
1. 更新のロスト
2. 書き込みスキュー

## 更新のロスト
アプリケーションが何らかの値をデータベースから読み取り、その値を変更して書き戻す場合に生じることがあります。

```mermaid
sequenceDiagram
A->>DB: Read(X)
DB->>A: X=5

B->>DB: Read(X)
DB->>B: X=5

A->>DB: X=X+1
A->>DB: Commit
DB->>A: X=6

B->>DB: X=X+1
B->>DB: Commit
DB->>B: X=6(トランザクションAの更新がロスト)
```

### 対応方法
- DBが提供するアトミックな書き込み操作を使う

```sql
UPDATE counters SET value = value + 1 WHERE key = 'foo';
```

- アプリケーションで明示的にロックする
- compare-and-set(最後の読み取り時から値が変化していない場合のみ更新を行う)
- (実装によっては更新のロストを自動検出できる。MySQL(InnoDB)ではできないらしい)

## 書き込みスキュー
トランザクションが何らかの値を読み取り、その値に基づいて判断を行った上でそれぞれ値を更新する場合に起きえます。判断の結果が、他のトランザクションの書き込みによって真でなくなってしまう場合を指します。

例として、病院の当直管理アプリケーションを想定します。医師は、最低でも一人の同僚が当直に入っていれば(currently_on_call>=2)自分の当直を取り消せます。

```mermaid
sequenceDiagram
participant Alice
participant DB as データベース
participant Bob

Alice->>DB: begin transaction
Bob->>DB: begin transaction

Alice->>DB: select count(*) (on_call=true, shift_id=1234)
DB-->>Alice: currently_on_call=2

Bob->>DB: select count(*) (on_call=true, shift_id=1234)
DB-->>Bob: currently_on_call=2

Alice->>DB: if >=2 then update set on_call=false for Alice

Bob->>DB: if >=2 then update set on_call=false for Bob

Alice->>DB: commit transaction
Bob->>DB: commit transaction

Note over DB: 最終的にcurrently_on_callは0になってしまう

```

### 対応方法
- 自動的に回避するためには、直列化可能分離レベルが必要。
- Repeatable Readで回避するには、アプリケーションでトランザクションが依存する行を明示的にロックする。
- ユニーク制約で回避できるケースもある(ユニークなユーザ名の登録操作等)。


# 参考
- [データ志向アプリケーションデザイン](https://www.oreilly.co.jp/books/9784873118703/)
- [MySQLリファレンス トランザクション分離レベル](https://dev.mysql.com/doc/refman/8.0/ja/innodb-transaction-isolation-levels.html)
- [トランザクション分離レベルのケースと対応方法](https://christina04.hatenablog.com/entry/transaction-isolation-level)

MySQL(InnoDB)におけるデフォルトのトランザクション分離レベルにおいて起きうる問題

別の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)

Golangで、プロジェクト内で独自に定めたコーディング規約が遵守されていることを確認する


## 概要

チームやプロジェクトで独自に定めたコーディング規約が遵守されていることを確認するために、OPA・Regoを使ってコードを検査する。Golangでの実装を想定している。

## 仕組み

まず、検査対象のコードをASTに変換する。ASTは、抽象構文木のことで、コードの構造を表現したデータ構造のこと。ASTを使うことで、コードの構造をプログラムで扱えるようになる。
Regoで記述したコーディング規約をポリシーとして、ASTをインプットとしてOPAに渡すことで、コーディング規約に違反している箇所を検出することができる。

## goast

上記を簡単に実現するために、[goast](https://github.com/m-mizutani/goast)というツールを使用する。goastはユーザが定義したポリシーをもとに上記をまとめて行ってくれる。出力した結果に`pos`という名前でPos値を渡すことで、出力に違反しているコードを表示することもできる。

```rego
res := {
    "msg": "fmt.Println is not allowed",
    "pos": input.Node.X.Fun.X.NamePos,
    "sev": "ERROR"
}
```

## 実装
goastを使って以下のようなルールを記述してみる。

### 1. メソッドのレシーバは1文字とする
- 検査対象のGoコード(main.go)
```go
package main

func main() {}

type Test struct{}

func (t Test) Valid() {}

func (tt Test) Invalid() {}
```

- ポリシー(policy.rego)
```rego
# メソッドのレシーバ名は1文字とする
fail[res] {
    input.Kind == "FuncDecl"
    input.Node.Recv != null
    count(input.Node.Recv.List[x].Names[y].Name) != 1

    res := {
        "msg": "method receiver name should be 1 character",
        "pos": input.Node.Recv.List[x].Names[y].NamePos,
        "sev": "ERROR"
    }
}
```

- 実行結果
```shell
$ goast eval -p ./policy.rego main.go
[main.go:9] - method receiver name should be 1 character

func (tt Test) Invalid() {}
      ~~~~~~~~~~~~~~~~~~~~~


        Detected 1 violations
```

- テスト(policy_test.rego)をテーブル駆動テスト風に記述してみる

```rego
package goast

test_policy {
    not _test_policy
}

_test_policy {
    testCases := [
        {
            "name": "レシーバがない",
            "wantErr": false,
            "data": {
                  "Path": "main.go",
                  "FileName": "main.go",
                  "DirName": ".",
                  "Node": {
                    "Doc": null,
                    "Recv": null,
                    "Name": {
                      "NamePos": 20,
                      "Name": "main",
                      "Obj": null
                    },
                    "Type": {
                      "Func": 15,
                      "TypeParams": null,
                      "Params": {
                        "Opening": 24,
                        "List": [],
                        "Closing": 25
                      },
                      "Results": null
                    },
                    "Body": {
                      "Lbrace": 27,
                      "List": [],
                      "Rbrace": 28
                    }
                  },
                  "Kind": "FuncDecl"
            }
        },
        {
            "name": "レシーバが1文字",
            "wantErr": false,
            "data": {
                  "Path": "main.go",
                  "FileName": "main.go",
                  "DirName": ".",
                  "Node": {
                    "Doc": null,
                    "Recv": {
                      "Opening": 56,
                      "List": [
                        {
                          "Doc": null,
                          "Names": [
                            {
                              "NamePos": 57,
                              "Name": "t",
                              "Obj": null
                            }
                          ],
                          "Type": {
                            "NamePos": 59,
                            "Name": "Test",
                            "Obj": null
                          },
                          "Tag": null,
                          "Comment": null
                        }
                      ],
                      "Closing": 63
                    },
                    "Name": {
                      "NamePos": 65,
                      "Name": "Valid",
                      "Obj": null
                    },
                    "Type": {
                      "Func": 51,
                      "TypeParams": null,
                      "Params": {
                        "Opening": 70,
                        "List": [],
                        "Closing": 71
                      },
                      "Results": null
                    },
                    "Body": {
                      "Lbrace": 73,
                      "List": [],
                      "Rbrace": 74
                    }
                  },
                  "Kind": "FuncDecl"
            }
        },
        {
            "name": "レシーバが2文字",
            "wantErr": true,
            "data": {
                  "Path": "main.go",
                  "FileName": "main.go",
                  "DirName": ".",
                  "Node": {
                    "Doc": null,
                    "Recv": {
                      "Opening": 106,
                      "List": [
                        {
                          "Doc": null,
                          "Names": [
                            {
                              "NamePos": 107,
                              "Name": "tt",
                              "Obj": null
                            }
                          ],
                          "Type": {
                            "NamePos": 110,
                            "Name": "Test",
                            "Obj": null
                          },
                          "Tag": null,
                          "Comment": null
                        }
                      ],
                      "Closing": 114
                    },
                    "Name": {
                      "NamePos": 116,
                      "Name": "Invalid",
                      "Obj": null
                    },
                    "Type": {
                      "Func": 101,
                      "TypeParams": null,
                      "Params": {
                        "Opening": 123,
                        "List": [],
                        "Closing": 124
                      },
                      "Results": null
                    },
                    "Body": {
                      "Lbrace": 126,
                      "List": [],
                      "Rbrace": 127
                    }
                  },
                  "Kind": "FuncDecl"
            }
        }
    ]

    tc := testCases[_]
    out := fail with input as tc.data
    tc.wantErr != (count(out) > 0)
}
```

実行
```shell
$ opa test -v .
policy_test.rego:
data.goast.test_policy: PASS (687.958µs)
--------------------------------------------------------------------------------
PASS: 1/1
```

### 2. Publicな関数にはコメントをつける
- Goコード
```go
package main

func main() {}

// Valid is valid
func Valid()   {}
func valid()   {}
func Invalid() {}
```

- ポリシー
```rego
# Publicな関数にはコメントをつける
fail[res] {
    input.Kind == "FuncDecl"
    is_uppercase(substring(input.Node.Name.Name, 0, 1))
    input.Node.Doc == null

    res := {
        "msg": "public function should have comment",
        "pos": input.Node.Name.NamePos,
        "sev": "ERROR"
    }
}

is_uppercase(str) {
    str == upper(str)
}
```

- 実行
```shell
goast eval -p ./policy.rego main.go
[main.go:8] - public function should have comment

func Invalid() {}
     ~~~~~~~~~~~~


        Detected 1 violations
```

### 3. handler pkg以外がhttp pkgに依存することを禁止する
- ディレクトリ構成
```shell
internal
├── handler
│   └── handler.go
└── service
    └── service.go

3 directories, 2 files
```

- handler.go
```go
package handler

import "net/http"

func handler() {
	_, _ = http.Get("http://example.com/")
}
```

- service.go
```go
package service

import "net/http"

func service() {
	_, _ = http.Get("http://example.com/")
}
```

- ポリシー
```rego
# handler pkg以外がhttp pkgに依存することを禁止する
fail[res] {
    input.Kind == "File"
    input.DirName != "internal/handler"
    input.Node.Imports[x].Path.Value == "\"net/http\""

    res := {
        "msg": "handler pkg should not depend on http pkg",
        "pos": input.Node.Imports[x].Path.ValuePos,
        "sev": "ERROR"
    }
}
```

- 実行結果
```shell
$ goast eval -p ./policy.rego internal
[internal/service/service.go:3] - handler pkg should not depend on http pkg

import "net/http"
       ~~~~~~~~~~


        Detected 1 violations
```

## 参考

- https://zenn.dev/mizutani/articles/go-static-analysis-with-rego
- https://zenn.dev/mizutani/articles/go-static-analysis-with-rego-ex
- https://pkg.go.dev/go/ast

OPA・Regoでコーディング規約が守られている事を検査する


### コマンド
vast.xmlというファイルにVASTのXMLを保存したと仮定(インラインVASTの場合)

```shell
xmllint vast.xml --xpath "//VAST/Ad/InLine/Creatives/Creative/Linear/MediaFiles/*" |  grep -E -o 'https:[a-zA-Z0-9/\.\,\_\\-]+mp4' | xargs -n 1 curl -OJ
```

VASTに含まれるMediaFileを一括でダウンロードするコマンド

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の接続トラブルの原因を切り分ける

Go標準の構造化ロガーライブラリ、slogの使い方


# slog
[Go1.21](https://tip.golang.org/doc/go1.21)で構造化ロガー[slog](https://pkg.go.dev/golang.org/x/exp/slog)が標準ライブラリとして追加された。1.20以前にもlogパッケージは存在したが、テキストでしか出力できず、ログレベルの設定等もできなかった。そのためZap等のサードパーティライブラリを使用する事が多かった。
slogは構造化ログとログレベルを提供する。

## 基本的な使い方
ごく簡単に使うことができる。
```go
slog.Info("hello", "count", 3)
```
出力は以下。
```go
2022/11/08 15:28:26 INFO hello count=3
```

## アーキテクチャ
[![Image from Gyazo](https://i.gyazo.com/211e1610903895836e0d6ac0da81bebe.png)](https://gyazo.com/211e1610903895836e0d6ac0da81bebe)
- Logger: ロガーのフロントエンド。ログ出力のためのメソッドを提供する。呼び出しの度にRecordを作成する。
- Record: RecordはHandlerに渡されて出力される。
- Handler: ロガーのバックエンド。出力形式や出力先などを制御する。

## JSON形式で出力する
JSONHandlerを使用することで、JSON形式でログを出力できる。
```go
logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
logger.Info("hello", "count", 3)
```

```go
{"time":"2022-11-08T15:28:26.000000000-05:00","level":"INFO","msg":"hello","count":3}
```

## ログレベルのカスタマイズ
slogのログレベルはデフォルトでDebug,Info,Warn,Errorの4種類定義されている。
```go
type Level int

const (
LevelDebug Level = -4
LevelInfo  Level = 0
LevelWarn  Level = 4
LevelError Level = 8
)
```

Levelはint型で-4から4刻みで定義されているので、独自のレベルを定義してフィルタすることもできる。
```go
const LevelFatal = slog.Level(12)
logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
    Level: LevelFatal,
}))
logger.Log(context.Background(), LevelFatal, "test")
```

ただし、上記だと以下のようにログレベルがいい感じに表示されない。

```go
{"time":"2023-09-24T02:31:00.353259+09:00","level":"ERROR+4","msg":"test"}
```

独自に定義したログレベル名を表示するには以下のようにする。
```go
logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
    ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
        // NOTE: slogにログレベル`FATAL`を追加
        if a.Key != slog.LevelKey {
            return a
        }
        if level := a.Value.Any().(slog.Level); level == LevelFatal.ToSlogLevel() {
            a.Value = slog.StringValue("FATAL")
        }
        return a
    },
}))
```

# 参考
- [プロポーザル](https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md)
- [A consistent logging format for Go](https://www.youtube.com/watch?v=gd_Vyb5vEw0)
- [Goの新しい構造化ロガーを体験しよう](https://gihyo.jp/article/2023/02/tukinami-go-04)
- [Go 1.21連載始まります＆slogをどう使うべきか ](https://future-architect.github.io/articles/20230731a/)
- [Go1.21 log/slogパッケージ超入門](https://zenn.dev/88888888_kota/articles/7e97ff874083cf)

slogの使い方


## 概要

- 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でインシデント調査を行う


## モニタリングとは

- モニタリングとは、システムに関するリアルタイム定量データの収集、処理、集計、表示を行うことである。
- モニタリングはホワイトボックスモニタリングとブラックボックスモニタリングに分けられる。


| ホワイトボックスモニタリング | システムの内部によって公開されているメトリクスに基づくモニタリング |
| --- | --- |
| ブラックボックスモニタリング | ユーザーが目にする外部の振る舞いをモニタリングすること |
- モニタリングシステムは、以下の2つの疑問に答える必要がある。
1. 何が壊れたのか？
2. なぜ壊れたのか？

## オブザーバビリティとは

- オブザーバビリティとは、複雑なITシステムやアプリケーションの状態といったデジタル上の動きを常に把握するという性質、およびそのための取り組み。
- オブザーバビリティに必要不可欠な3要素
1. テレメトリーデータの収集
2. テレメトリーデータの分析
3. テレメトリーデータの可視化

## モニタリングとオブザーバビリティの違い

- モニタリング(監視)との違いは、モニタリングは事前に定義された異常が発生したときに通知するだけだが、オブザーバビリティを備えたシステムでは、問題が生じた原因とシステムの動作がどの様になっているかをリアルタイムに把握できる。

## どのようなメトリクスを取得すべきか？

### 4大シグナル

1. レイテンシ
2. トラフィック
3. エラー
4. サチュレーション(サービスがどれだけ「手一杯」になっているか。システムの利用率)

### USEメソッド

USEメソッドは、システムのパフォーマンス分析の方法論。すべてのリソースについて、以下を確認する。

1. Utilization(使用率)
2. Saturation(飽和状態)
3. Errors(エラー)

### REDメソッド

REDメソッドは、マイクロサービスを監視するための方法論。

1. Rate
2. Errors
3. Duration

### USEメソッドとREDメソッド

- 両方を使用することを推奨。
- REDメソッド: ユーザ影響を直接表現しているデータ
- USEメソッド: システムの内部状況を表現しているデータ

## 参考

- [New Relic実践入門](https://www.shoeisha.co.jp/book/detail/9784798166599)
- [SRE サイトリライアビリティエンジニアリング](https://www.oreilly.co.jp/books/9784873117911/)
- [入門監視](https://www.oreilly.co.jp/books/9784873118642/)
- [AWSの記事『モニタリングとオブザーバビリティ」](https://aws.amazon.com/jp/products/management-and-governance/use-cases/monitoring-and-observability/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc&blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc)
- [AbemaTVにPrometheusというモニタリングシステムを導入した話](https://developers.cyberagent.co.jp/blog/archives/3814/)
- [The USE Method](https://www.brendangregg.com/usemethod.html)
- [The RED Method: How to Instrument Your Services](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/)
- [Heroku Go言語メトリクス](https://devcenter.heroku.com/ja/articles/language-runtime-metrics-go)

どのようなメトリクスを監視すべきか？USEメソッドとREDメソッド


## はじめに

CDNについて勉強したので概要をメモします。

## CDNとはなにか

CDN(コンテンツ・デリバリー・ネットワーク)とは、「地理的に分散されたネットワーク品質の良いコンピューティングリソースのプラットフォーム」である。

### CDNの構成要素

1. エッジサーバー(Proxy)
2. 広域負荷分散が可能なLB
3. インフラ

## CDNを利用するメリット

- 配信の高速化・安定化
- セキュリティ
- 付加サービス

### 配信の高速化・安定化

- CDNは世界中に高品質のネットワーク、エッジサーバー（クライアントと近い位置にあるサーバー）を有するため、クライアントに地理的に近い位置から、高速かつ安定した配信が可能となる。
- クライアントに近い位置からキャッシュを返すことができる(キャッシュがない状態でも、パフォーマンスが向上する可能性がある)。
- CDNは基本的に従量課金であり、大規模なトラフィックに耐えられるため、大規模なサイトでは自前でインフラを構築するよりコスト上有利である。

### セキュリティ

CDNはセキュリティ対策としても有効である。

1. DDoS 対策
2. Web Application Firewall（WAF）
3. Bot 対策

### 付加サービス

CDNによっては、以下のような付加サービスを提供している。
- エッジでのコード実行（JavaScript などを CDN のエッジサーバーで実行）
- 画像最適化
- HTML/CSS/JavaScript の minify

## CDNの機能

CDNは以下のような機能を有している事が多い。

1. 柔軟なキャッシュ設定
2. ルーティング
3. キャッシュの消去
4. アクセス情報の可視化
5. HTTP リクエスト／レスポンスの変更
6. DDoS 対策
7. Web Application Firewall
8. エッジでのコード実行（JavaScript などを CDN のエッジサーバーで実行）
9. 画像最適化
10. HTML/CSS/JavaScript の minify

## CDNに関連するHTTPヘッダ

- Cache-Controlヘッダ
  - no-cache: CDNがキャッシュしていても、それを無視してオリジンへリクエストしてほしいと要請
  - s-maxage: max-ageと同様、確認せずキャッシュを利用できる期間を表す。共有キャッシュに関する設定値で、max-ageより優先される。
- x-cacheヘッダ: CDNにおいてキャッシュヒットしたかを表す。ただし、値はCDNによってバラバラ。


## CDNを利用する上での注意点

- 各Proxy・CDNでCache-Controlの解釈・クエリ文字列の処理の方針が異なる。
- privateなコンテンツがsharedとしてキャッシュされると、個人情報流出などにつながる恐れがある。
  - 2017年にメルカリで発生したインシデントは、CDNプロバイダを切り替えた際のCache-Controlの解釈の違い・仕様の違いが原因だった(5)。
- 各Proxy・CDNでクエリ文字列の処理の方針が異なる。
- トラフィック制限があるため、大規模なトラフィックが予想される場合は事前にCDN事業者に相談する。
- コンテンツ制限
- オリジンのアドレスなど隠したい情報を隠す。
- 場合によってはウォームアップ(エッジにキャッシュを入れておく)を使用する。

## 参考
1. 『Web配信の技術―HTTPキャッシュ・リバースプロキシ・CDNを活用する』
2. 『Real World HTTP第2版』
3. 『達人が教えるWebパフォーマンスチューニング-〜ISUCONから学ぶ高速化の実践』
4. [CDN（コンテンツ・デリバリー・ネットワーク）とは？](https://www.akamai.com/ja/our-thinking/cdn/what-is-a-cdn)
5. [CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして](https://engineering.mercari.com/blog/entry/2017-06-22-204500/)

CDNについての勉強メモ


## はじめに

## チートシート
### 基礎(ffprobe)

余計な出力なし。インプットとして渡す動画は、ローカルでもネット上の動画でもいける。すごいね！

```shell
ffprobe -hide_banner -pretty -show_format -show_streams input.mp4
```

### プログレッシブ→インタレース

インタレースがなぜだめなのかを実験する。

```shell
ffmpeg -i input.mp4 -vf "tinterlace=5" interlace.mp4
```

### VBR/CBRの判定

- ffprobe nal-hrd vbr / cbr 記載なし
- maxrateが平均より上だったらVBR

### フレームレート変更

```shell
ffmpeg -i input.mp4 -r 10 framerate.mp4
```

### 参照フレーム数取得

ffprobeでrefsを参照(この値は注意が必要らしい。詳細はよくわからず)。

### ラウドネス取得
ffmpegでebur128フィルタを使用する。

```shell
ffmpeg -nostats -i input.mp4 -vn -y -filter_complex "ebur128=framelog=verbose" -f null -
```

### ラウドネス可視化

```shell
ffmpeg -i input.mp4 -filter_complex "ebur128=video=1:target=-23.0" loudness_visual.mp4
```

### ラウドネスを-18LKFSにする

```shell
ffmpeg -i input.mp4 -filter_complex "loudnorm=I=-18" loudness.mp4
```

### 音声ピーク値(サンプルピーク)取得

ffmpegでebur128フィルタを使用する。

```shell
ffmpeg -nostats -i input.mp4 -vn -y -filter_complex "ebur128=framelog=verbose:peak=sample" -f null -
```

## 参考
- 『FFmpegの本』
- 『FFmpegのオーディオフィルタの本』

ffmpeg・ffprobeコマンドチートシート


# はじめに
[『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践』](https://www.amazon.co.jp/%E4%BD%93%E7%B3%BB%E7%9A%84%E3%81%AB%E5%AD%A6%E3%81%B6-%E5%AE%89%E5%85%A8%E3%81%AAWeb%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9-%E7%AC%AC2%E7%89%88-%E8%84%86%E5%BC%B1%E6%80%A7%E3%81%8C%E7%94%9F%E3%81%BE%E3%82%8C%E3%82%8B%E5%8E%9F%E7%90%86%E3%81%A8%E5%AF%BE%E7%AD%96%E3%81%AE%E5%AE%9F%E8%B7%B5-%E5%BE%B3%E4%B8%B8/dp/4797393165)を読んだので、内容をまとめてみます。

# 前提知識

### 受動的攻撃とは

- 受動的攻撃とは、Webサイトの利用者に罠をしかけることにより、そのユーザを通してアプリケーションを攻撃する手法
- サイトをまたがった受動的攻撃では以下のように攻撃する
1. 利用者が罠サイトを閲覧
2. 罠サイトから、仕掛けを含むHTMLをダウンロードする
3. HTMLの仕掛けが発動して正規のサイトに攻撃のリクエストを送信する
4. 正規サイトからJSなどの仕掛けを含むレスポンスが返る

### 同一オリジンポリシーとは

- JavaScriptなどのクライアントからサイトをまたがったアクセスを禁止するセキュリティ上の制限。
- 受動的攻撃を防止するために用意された。
- 「同一オリジン」であるとは、以下のすべてを満たす場合
1. URLのホストが一致
2. スキームが一致
3. ポート番号が一致

### CORSとは

- WebアプリケーションにおいてJSの活用が進むようになり、同一オリジンポリシーの制限を超えてサイト間でデータをやり取りしたいというニーズが強くなった。
- それを実現するため、CORSが策定された。
- CORSは、同一オリジンポリシーに依存するアプリケーションとの互換性を保ちながら、異なるオリジンとのデータ交換を可能にするもの。
- 情報の提供元がAccess-Control-Allow-Originヘッダを出力することで、XMLHttpRequestでのアクセスを許可できる
- 仕組み
- シンプルなリクエスト
- 以下の条件を満たす場合、相手側の許可なしにXMLHttpRequestを用いてリクエストを送信可能(HTMLフォームで送れる場合と同程度のリスクのリクエスト)
1. メソッドはGET/HEAD/POSTのいずれか
2. リクエストヘッダは以下に限る
1. Accept
2. Accept-Language
3. Content-Language
4. Content-Type
3. Content-Typeヘッダは以下のいずれか
1. application/x-www-form-urlencoded
2. multipart/form-data
3. text/plain
- プリフライトリクエスト
- 上記を満たさない場合は、プリフライトリクエストを送信する必要がある

### CORSはなぜ受動的攻撃を防げるのか

<img src="https://i.gyazo.com/14d26146e3c02f94095ceb97b3a464c9.png" alt="drawing" width="600"/>

# Webアプリケーションの主な脆弱性/攻撃手法と対策

| 攻撃 | 概要 | 典型的な原因 | 発生箇所 | 影響を受けるページ | 影響の種類 | 影響の度合い | 利用者関与 | 対策の概要 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [ ] XSS | 開発者の意図しない形でHTMLやJSを注入・変形される | HTML生成の際に特殊記号を正しく扱っていないこと | Webアプリケーション上でHTML,JavaScriptを生成している箇所 | すべてのページ | Webサイト利用者のブラウザ上でのJSの実行・偽情報の表示 | 中~大 | 必要 | 1. 属性値はダブルクォートで囲む 2. HTMLで特別な意味を持つ記号文字をエスケープする |
| [ ] SQLインジェクション | シングルクォートなどを用いてリテラルからはみ出した文字をSQL文として認識させ、アプリケーションが呼び出すSQL文を変更する | リテラルの扱いの不備 | SQL呼び出しをしている箇所 | すべてのページ | 情報漏えい・データ改ざん・認証の回避・プログラムの実行・ファイルの参照/更新 | 大 | 不要 | 静的プレースホルダ(値のバインドをデータベースエンジンで行う)を利用してSQLを呼び出す |
| [ ] CSRF | アプリケーションの「重要な処理」を勝手に実行させる | Webの以下の性質のため、正規のリクエストと不正なリクエストの見分けがつかない 1. formのaction属性にはどのドメインのURLも指定できる 2. Cookieに保存されたセッションIDは自動的に送信される | 以下のいずれかのサイト上の「重要な処理」が行われるページ 1. Cookieのみでセッション管理が行われているサイト 2. HTTP認証・TLSクライアント証明書のみで利用者の識別をしているサイト | CSRF脆弱性のあるページ | 被害者の権限で「重要な処理」を実行させられる | 中~大 | 必要 | 「重要な処理」の前に正規利用者からのリクエストであることを確認する(CSRF対策トークン・パスワード再入力・Referer確認) |
| [ ] クリックジャッキング | iframeとCSSを巧妙に利用して、透明にした攻撃対象ページと罠のサイトを重ね合わせ、利用者が気づかないうちに攻撃対象サイトでのクリックを誘導する | HTMLの仕様を巧妙に悪用 | マウスなどの操作のみで「重要な処理」を実行でき、かつ認証を要するページ | クリックジャッキング脆弱性のあるページ | 被害者の権限で「重要な処理」を実行させられる | 中~大 | 必要 | 「重要な処理」の実行ボタンなどがあるページでX-Frame-Optionヘッダを出力する |
| [ ] セッションハイジャック | 第三者がセッションIDを悪用してなりすます | 1. セッションIDが推測可能 2. セッションIDを外部から強制できる 3. セッションIDをURLに埋め込んでいる | セッションIDを生成している場所 | セッション管理をしているページすべて | なりすまし | 大 | 不要 | 1. 実績のあるセッション管理機構を利用する(自作しない) 2. ログイン時にセッションIDを変更する 3. URL埋め込みのセッションIDの禁止 |
| [ ] オープンリダイレクト | 任意のドメインにリダイレクトできる脆弱性(フィッシングに悪用可能) | 以下の両方 1. リダイレクト先のURLを外部から指定できる 2. リダイレクト先のドメイン名のチェックがない | 外部から指定したURLにリダイレクト可能な箇所 | Webアプリケーションの利用者が被害を受ける | フィッシングサイトへの誘導・マルウェアを配布される | 中~大 | 必要 | 以下のいずれか 1. リダイレクト先の固定 2. あらかじめ許可されたドメインのみリダイレクトする |
| [ ] HTTPヘッダインジェクション | 任意のレスポンスヘッダの追加、レスポンスボディの偽造 | 外部から指定したパラメータに含まれる改行をそのままレスポンスとして出力する | 外部から指定したパラメータに基づいてHTTPレスポンスヘッダを出力している箇所 | すべてのページ | なりすまし、偽ページの表示、キャッシュ汚染 | 中~大 | 必要 | 以下のいずれか 1. 外部からのパラメータをHTTPレスポンスヘッダとして出力しない 2. パラメータ中の改行コードをチェックする |
| [ ] ディレクトリトラバーサル | アプリケーションの意図しないファイルに対して閲覧・改ざん・削除をする | 以下の3つ 1. ファイル名を外部から指定できる 2. ファイル名として、異なるディレクトリを指定できる 3. ファイルに対するアクセス可否をチェックしていない | ファイル名を外部から指定できるページ | すべてのページ | 秘密情報の漏洩、データの改竄・削除、任意のスクリプトの実行、アプリケーションの機能停止 | 大 | 不要 | 以下のいずれか 1. 外部からファイル名を指定できる仕様を避ける 2. ファイル名にディレクトリ名が含まれないようにする 3. ファイル名を英数字に限定する |
| [ ] OSコマンドインジェクション | 意図しないOSコマンドを実行する | シェルのメタ文字がエスケープされていない | シェルを呼び出す機能のある関数を実行している場所 | すべてのページ | 秘密情報の漏洩、データの改竄・削除、外部への攻撃、アプリケーションの機能停止 | 大 | 不要 | 以下のいずれか 1. シェル呼び出し機能のある関数の利用を避ける 2. シェル呼び出し機能のある関数には外部からのパラメータを渡さない 3. OSコマンドにわたすパラメータを安全な関数によりエスケープする |

# 参考

- [体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践](https://www.amazon.co.jp/%E4%BD%93%E7%B3%BB%E7%9A%84%E3%81%AB%E5%AD%A6%E3%81%B6-%E5%AE%89%E5%85%A8%E3%81%AAWeb%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9-%E7%AC%AC2%E7%89%88-%E8%84%86%E5%BC%B1%E6%80%A7%E3%81%8C%E7%94%9F%E3%81%BE%E3%82%8C%E3%82%8B%E5%8E%9F%E7%90%86%E3%81%A8%E5%AF%BE%E7%AD%96%E3%81%AE%E5%AE%9F%E8%B7%B5-%E5%BE%B3%E4%B8%B8/dp/4797393165)


『体系的に学ぶ 安全なWebアプリケーションの作り方』の簡単なまとめ


# 概要
gocsvで生成するCSVのすべてのセルをダブルクォーテーションで囲みたかった。
[ネットで見つけた記事](https://qiita.com/developer-kikikaikai/items/af278f52cb06cc0f430d)とは別パターンの実装をしてみた。

# 実装

## 方針
ネットで見つけた記事では、生成したCSVをデコードして、各セルをダブルクォーテーションで囲った後、もう一度エンコードしている。

自分は、以下の方法で実装してみた。
gocsvでは、デフォルトでは内部でencoding/csvのWriter構造体を使用している。そこで、
1. gocsvのCSVWriterインターフェイスを実装する構造体を作成する
2. ↑で作成した構造体に、encoding/csvのWriterの実装を参考に、すべてのセルをダブルクォーテーションで囲むWriteメソッドを生やす
3. ↑をgocsvのMarshalCSVメソッドに渡す

### [gocsvのCSVWriterインターフェイス](https://github.com/gocarina/gocsv/blob/ad3251f9fa25/safe_csv.go#L9)

```go
type CSVWriter interface {
	Write(row []string) error
	Flush()
	Error() error
}
```

### ↑を実装するカスタム構造体

```go
type customCSVWriter struct {
	w *bufio.Writer
}

func NewCustomCSVWriter(w io.Writer) gocsv.CSVWriter {
	return &customCSVWriter{
		w: bufio.NewWriter(w),
	}
}

// Write writes すべてのセルをダブルクォーテーションで囲んだCSV
// encoding/csvのWriteメソッド(https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/encoding/csv/writer.go;l=48)を一部改修したもの
// 違いは以下
// 1. すべてのセルをダブルクォーテーションで囲む
// 2. 区切り文字は`,`固定
// 3. 改行文字に`\r\n`を使用するオプションは無効
func (w *customCSVWriter) Write(record []string) error {
	for n, field := range record {
		if n > 0 {
			if _, err := w.w.WriteRune(','); err != nil {
				return err
			}
		}

		if err := w.w.WriteByte('"'); err != nil {
			return err
		}
		for len(field) > 0 {
			// Search for special characters.
			i := strings.IndexAny(field, "\"\r\n")
			if i < 0 {
				i = len(field)
			}

			// Copy verbatim everything before the special character.
			if _, err := w.w.WriteString(field[:i]); err != nil {
				return err
			}
			field = field[i:]

			// Encode the special character.
			if len(field) > 0 {
				var err error
				switch field[0] {
				case '"':
					_, err = w.w.WriteString(`""`)
        case '\r':
          err = w.w.WriteByte('\r')
				case '\n':
          err = w.w.WriteByte('\n')
				}
				field = field[1:]
				if err != nil {
					return err
				}
			}
		}
		if err := w.w.WriteByte('"'); err != nil {
			return err
		}
	}

	err := w.w.WriteByte('\n')
	return err
}

func (w *customCSVWriter) Flush() {
	w.w.Flush()
}

func (w *customCSVWriter) Error() error {
	_, err := w.w.Write(nil)
	return err
}

```

### ↑を呼び出すコード
```go
buffer := bytes.Buffer{}
csvWriter := NewCustomCSVWriter(&buffer)
err := gocsv.MarshalCSV(&(CSVにしたい構造体など), csvWriter)
```


# 参考
- [gocsv](https://github.com/gocarina/gocsv)
- [ネットで見つけた記事](https://qiita.com/developer-kikikaikai/items/af278f52cb06cc0f430d)


gocsvですべてのセルをダブルクォーテーションで囲む


## はじめに
[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)

GlueからAuroraのMySQLにJDBC接続する

マージコミットの#数字(なんていうのかわからない)だけを抽出してMarkdownのリスト形式にする


```git
git log --merges --oneline --reverse | tail -n 10 | awk '{print $5}' | sed -e "s/.*/- &/g"
```

gitでマージコミットの#数字(なんていうのかわからない)だけを抽出してMarkdownのリスト形式にする

gitでmain以外のブランチを削除するコマンド


```git
git branch | egrep -v '\*main' |  xargs git branch -D
```

masatora.net