AWS関連のことを調べてみた2023年01月04日

自己流AWSセキュリティインシデント発生時のMITRE ATT&CKの活用

# はじめに
2023年、最初のブログはAWSセキュリティについて書きます。

MITRE ATT&CK（マイターアタック）という素晴らしいフレームワークには、非常に多くのナレッジが蓄積・公開されています。
パブリッククラウドサービスについても、各種クラウドごとにも纏められています。

さまざまな活用方法があるとは思いますが、自分なりの使い方の一つを共有しておきたいと思います。

今回、紹介するのは、インシデント発生後の再発防止についてです。

# 手順の概要
インシデント発生後、再発防止策の検討の際には、攻撃内容をもとにセキュリティホールを埋める対応を行いますが、多くの場合、担当者の知識ベースで考察します。

経験のあるエンジニアの場合、当初漏れてしまっていた対策も、この再発防止策を検討する際に気付けることが多いのですが、ここでMITRE ATT&CKと照らし合わせることで、攻撃者視点でのプロセスごとでの手順と対策を体系的に確認ができます。
また、他の対策に気付ける可能性もあります。

MITRE ATT&CKでは、攻撃者が行うプロセスを14ステップのTactic(s)と呼びます。

【Route53】「ゾーンシフト」を活用してAZ障害からトラフィックを素早く回避させよう【ARC】

# はじめに
re:Invent2022にて、Route53のApplication Recovery Controller(ARC)の新機能として「ゾーンシフト(zonal shift)」が発表されました(プレビュー)。AZ障害発生時に、ELBへのトラフィックを問題のあるAZからルーティングを回避させることが出来る優れものです。

https://aws.amazon.com/jp/about-aws/whats-new/2022/11/amazon-route-53-application-recovery-controller-zonal-shift/

# Route53 Application Recovery Controllerとは
– Route53のARCは以下の3つの機能を提供
– 準備状況チェック
– リソースの準備状況を監視します
– ルーティング制御
– **マルチリージョン**アプリケーションのフェイルオーバーのためにトラフィックを再ルーティング
– ゾーンシフト
– **マルチAZ**

AWS CodeCommit の HTTPS Git 認証情報を生成

# 事前知識

https://qiita.com/ryome/items/efd37c3a49b54859ba68

https://qiita.com/ryome/items/ff2804be600cd5dcd61a

# AWS IAMアカウントの作成
1. IAMコンソールを開く。
2. ユーザーの詳細を開く。
3. 認証情報の `認証情報を生成` を押下する。
![03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44986

AWS IAMアカウントの作成とaws configureの設定

# 事前知識

https://qiita.com/ryome/items/efd37c3a49b54859ba68

# AWS IAMアカウントの作成
1. IAMコンソールを開く。
2. `ユーザ追加` を押下する。
3. `ユーザー名` を入力し、`アクセスキー・プログラムによるアクセス` にチェックを付ける。
4. `アクセス権限` を押下する。
![03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/449867/c8214

Amazon GuardDuty RDS Protectionについて調べてみた

# はじめに
re:Invent 2022のリリースの中でGuardDutyの新機能としてRDS Protectionが発表されました(プレビュー)。GuardDutyはEC2やS3、VPCフローログ、DNSログ、CloudTrail管理ログなどを継続的にモニタリングする事で悪意あるアクティビティを調査してくれる脅威検知サービスです。

https://aws.amazon.com/jp/about-aws/whats-new/2022/11/amazon-guardduty-rds-protection-preview/

今回のリリースではそのモニタリング対象としてRDSが追加されたという内容になります。まだプレビューでGAはされていませんが、具体的に何をしてくれるものなのかを再確認する意味も含めて調べてみようと思い、その記録として書いていきます。

# RDS Protectionがしてくれること
– AuroraDBインスタンスへの**ログインアクティビティの監視**
– 疑わしいアクティビティの検出(不正アクセスなど)
– 侵害された可能性のあるDBインスタンスに関するレポー

DynamoDB: 属性が動的なアイテムでの、既存アイテムの更新方法の検討

# 背景
DynamoDB のデータ更新時に、データのマージをしたかったので、方法を調査してみた

# 結論
とりあえず、以下2つの案が出来たけど・・なんだかなぁ‥という状況。
なんかもっと良い方法がありそうなんだが・・

1. [Update したい 属性に応じて、更新式を構成する](#updatecommandinput-をproperty-により-onoff-切り替える)
– 更新式の構成自体が面倒
1. [現状item を Get で取得して、マージ後に、Put で上書き](#getcommand-で既存データ取得してmerge-してから-put)
– Get でデータ取得が先に必要で、その分の処理が無駄・・。

# 試行
## PutCommand では、上書きされるので、使えない
Document にあるように・・”completely replace” されます。

試しにやってみたけど、完全に新しくなりました。

> Creates a new item, or replaces an old item with a new item. **If an

TerraformでAWSのIAMまわりをデプロイする

Terraformシリーズ第３弾ということで実際にどうコーディングしていくか、というのを書いていきたいと思います。まずは**IAM**から。そんなもん「Terraform Registry」見ればいいやんというツッコミが入らないよう、実際に環境を作っていて気になったポイントとかを交えつつ書いていきます:sparkles:

※過去の記事はこちら
第一弾：[TerraformでAWSリソースをデプロイしてみる](https://qiita.com/hiyanger/items/ca337f70ad4801072850)
第二弾：[TerraformでAWS環境をデプロイする前に認識しておくべきこと（tfstate.tf / providor.tf / output.tf / ディレクトリ構造）](https://qiita.com/hiyanger/items/9efdc570e6cfed5aab13)

## IAMポリシー
“`
resource “aws_iam_policy” “ポリシー名” {
name = “ポリシー名”
path = “

AWS Application Composer を試す

# 初めに
AWS Application Composerとは、AWSのアーキテクチャをグラフィカルに構築できるサービスです。(2022/12 時点でプレビュー)
主にサーバレスアーキテクチャを視覚的に構築できます。

詳しくは以下を参照。

https://aws.amazon.com/jp/application-composer/

# 試してみる
S3にオブジェクトがputされたことを検知し、Lambdaを実行する仕組みを作ってみます。

([S3のイベント通知設定][link-1]でLambdaを宛先にすることでLambdaを実行することもできるのですが、EventBridgeを挟んでいます。)

## プロジェクトの作成
マネコンから「AWS Application Composer」へアクセスし、

【AWS Lambda】Python外部ライブラリのimportにおけるUnable to import module ‘lambda_function’エラーの対処方法

# 概要

外部ライブラリを`import`したときに以下のエラーが発生した場合に**Layerを追加**して対応する

“`json:Response
{
“errorMessage”: “Unable to import module ‘lambda_function’: No module named ‘ライブラリ名'”,
“errorType”: “Runtime.ImportModuleError”,
“requestId”: “リクエストID”,
“stackTrace”: []
}
“`

# 対応手順

### エラーが発生する例
今回は例として、`requests`ライブラリを`import`する

以下のスクリプトをLambdaで実行するとエラーが発生する
“`python:lambda_function.py
import requests

def lambda_handler(event, context):

res = requests.get(‘https://example.com’)
body = ‘s

Amazon Redshiftのカーソル制限/トランザクション/データ型など気になった点

# はじめに
Amazon Redshiftについて、自分が気になった部分を書き出してみました。

# カーソルの制限
DECLAREの説明にあるとおり、カーソルに制限があります。

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/declare.html

> * 1 つのセッションで、同時に開くことができるカーソルは 1 つのみです。

1セッション1カーソルです。
ODBCを使って複数カーソルを使って処理しているアプリケーションは、接続先がRedshiftの場合だけカーソル操作を直列になるようにする必要があるようです。

> * すべてのカーソルの累積結果セットの最大サイズは、クラスターノードタイプに基づいて制限されます。より大きな結果セットが必要な場合は、XL または 8XL ノード構成にサイズ変更できます。
> 詳細については、「カーソルの制約」を参照してください。

1セッション1カーソルなので、「すべてのカーソル」というのは「すべての**セッション**のカーソル」ですね。

# トランザクション分離
「SERI

Terraformを使ってコンテナ経由でAWSのインフラを構築しよう！

## 前提
– AWSを使用
– AWSのアカウントを作成済み
– AWS Vaultをインストールおよび設定済み

AWS Valutをまだインストールおよび設定できてない方は以下の公式ドキュメントを参考にしてください

https://github.com/99designs/aws-vault

## なぜコンテナを使うのか？
複数プロジェクトで開発することが想定されるのでプロジェクトによってTerraformのバージョンが違うかと思います
そのため、ローカル上ではなく、プロジェクトごとにterraformのコンテナを作成し、コンテナ経由でTerraformを使う方がいいと考えています
今回はチュートリアルに従ってt2.microのEC2インスタンスを作成します

## ディレクトリ構成
“`
tree
.
├── .gitignore
└── infra
├── docker-compose.yml
└── main.tf
“`

### .gitignore
下記公式サイトからterraformの.gitignoreの内容をコピーします

https://

AWS Amplifyを使ってNext.jsをデプロイする（Basic認証、Monorepoもあり）

## AWS Amplifyとは
手軽にWeb,モバイルアプリケーションをデプロイすることができるAWSサービスの一つです。
Amplifyを活用することでインフラ周りはすべてAWSにおまかせして開発者はフロントエンドの開発に集中することができるため高速で開発→リリースすることができます。
またCI/CD環境の導入も自動的に導入でき、GitHubと連携すれば指定のブランチにプッシュされると自動でデプロイすることができます。

https://docs.aws.amazon.com/amplify/index.html

## 事前準備
今回はGitHubのリモートリポジトリからアプリをデプロイしていきたいので、事前にリモートリポジトリを作成して、アプリのコードを先程作成したリモートリポジトリへ上げておきましょう。

## デプロイ編
### Amplifyのマネジメントコンソールにアクセスする
AWSマネジメントコンソールから「Amplify」を検索してコンソールにアクセスします。
まだ一度もアプリケーションを作成していなければ画像のような画面となっていますので
「Get starte

AWSからGoogleへのドメイン移管

保有しているドメインがAWSにあるのですが、Googleに移管しようと思い、Google で申し込んだところ、認証コードを教えろ、と言われました。

AWS の R53 に行って、「登録済みドメイン」をクリックすると、以下のように出てきます。
ここの、「認証コード」の「コードの取得」をクリックしてその値をコピーして、Google の画面で入力すると、Google 側で処理（AWSに連絡して移管するぞー、と号令をかけるようです）が始まります。どうやら、10日程度はかかるようです。


上記は、AWS の R53 の画面となりますが、Google Domains の方では、以下のようになっています。

![dns_change_google.png](https://qiita-image-store.s3.ap-northeast-1.a

【初心者向け】【AWS SAA合格へ向けて】AWSにおけるネットワークの概要について

## 概要
AWS SAA合格へ向けてAWSについて１から勉強した際に学んだことを定期的にアウトプットしたいと思います
今回は
– Region(リージョン)
– VPC(バーチャルプライベートクラウド)
– AZ(アベイラビリティゾーン)
– パブリックサブネットとプライベートサブネット
– IGW(インターネットゲートウェイ)
– ルートテーブル
– NACL(ネットワークアクセスコントロールリスト)とSG(セキュリティグループ)の違い
– 踏み台サーバとNATゲートウェイ

について説明したいと思います
図に表すと以下のようになります

## Region
AWSのサービスを提供している地域のことで日本では
– 東京リージョン(ap-northeast-1)
– 大阪リージョン(ap-northeast-3)

の2種類

2022年にpythonとAWS Lambdaで作ったもの

# 1. まえがき
去年作ったプログラムのまとめ記事となります。

# 2. 競馬関係のTwitter BOT
2022年の初めに、[「AWSではじめるインフラ構築入門」](https://amzn.asia/d/9bYYI0P)の本を購入し、アプリを作成
自分でも作成して見ようと、興味がある競馬関連のTwitterのBOTを4つ作成

・1号機（今日のハクサン地方競馬出走情報Bot）

#園田競馬 9R ハクサンチェイス

— 今日のハクサン地方競馬出走情報Bot (@hakusan_keiba) December 30, 2022

・2号機（明日のメイショウ冠名馬中央競馬出走情報と今日の競走結果情報BOT）

今日のメイショウ冠馬中央競馬結果
中山05R メイショウゴルシ 10着（6番人気）
阪神09R メイショウフンケイ 6着（1番人気）
阪神09R メイショウカイト 7着（12番人気）
阪神09R メイショウミツヤス 11着（9番人気）
阪神12R メイショウツツジ 7着（15番人気）

— 明日のメイショウ冠名馬中央競馬出走情報と今日の競走結果情報BOT (@MeishoBot) December 28, 2022

– 3号機（マカオ競馬の日本人騎手レース結果Bot）

https://twitter.com/macau_keiba/status/16094690722778972

SAMで環境別にデプロイ

## やりたいこと
samで構築されるリソースを各環境(dev/prod)ごとに分けたい。

## 環境別に分ける方法
– samconfig.tomlを環境別に分けて記述する。
– template.yamlにパラメータとして環境情報を渡して、環境別に各リソース名を切り替える

## 構築するリソース
– S3
– Lambda
– DynamoDB

## template.yaml
Parametersで外部から環境情報を渡せるようにし、各リソース名を環境ごとに切り替える。
※関連個所のみ記載
“`
Parameters:
Env:
Type: String
AllowedValues:
– dev
– prod

Resources:
CreateThumbnailBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub create-thumbnail-test-${Env}
CreateThumbnailFunction:
T

API Gateway経由でLambdaを呼び出す

## 概要
API Gatewayを自身で構築したことがなかったので、簡単なものを構築してみた。
/test(GET)でLambdaを呼び出せるようにする。

## 手順
1. Lambda関数を作成
2. API GatewayでREST APIを作成
3. APIをデプロイする
4. APIにアクセス

## Lambda関数を作成
コードは初期のまま
“`
export const handler = async(event) => {
// TODO implement
const response = {
statusCode: 200,
body: JSON.stringify(‘Hello from Lambda!’),
};
return response;
};

AppFlow を使って、Google Analytics 4 から S3 にデータを連携してみた

# はじめに

Amazon AppFlow では、2022 の re:Invent で [22 個の新しいコネクタ](https://aws.amazon.com/jp/blogs/aws/announcing-additional-data-connectors-for-amazon-appflow/)が発表されました。この新しい 22 個のコネクタの中には、Google Analytics 4 も含まれています。Google Analytics 4 に蓄積されているデータを、データ分析に活かしていきたいと思われている方もいるのではないでしょか。

Amazon AppFlow を使って Google Analytics 4 のデータを、Amazon S3 といった他のデータストアに連携することが出来ます。今回は、Google Analytics 4 のデータを、Amazon S3 に定期的に csv で出力する方法を紹介します。

# Google Cloud : API の有効化

Google Analytics 4 からデータを取得する API の有効化がまずは必要です

(LIFF/React/AWS/IoT)LINEアカウントと自社サービスID/IoTデバイスを連携させる方法

# はじめに
IoTデバイスなどの自社サービス・IDとLINEアカウントを紐づけることで、通知やメッセージ送信など様々なことが可能になります。実装方法は公式リファレンスに記載されています。しかし、全て0から実装するとなると大変です。フロント・バックエンドが絡み合い、さらにはログイン画面も作らねばならず大掛かりな作業となります。ポイントを絞って実装内容を紹介致します。

# 事前準備
LIFFやLINEミニアプリなどの説明は割愛致します。
あらかじめ登録が必要なものです。

## LINE Developersの準備

下記2点を先にLINE Developersで登録しておきましょう。
この時点ではLIFFのエンドポイントはなくても大丈夫です。

* LINE ログイン
* Messaging API
* LIFFアプリの環境構築

https://developers.line.biz/ja/

#### LIFFアプリの環境構築

今回はReactで実装してます。下記コマンドを実装することでLIFFアプリを構築することができます。
“`
$ npx @line/create-li

AWS Control Tower Guide (ハンズオン) をやってみて気が付いたことを整理してみた

# はじめに

複数の AWS アカウントを管理するための Control Tower 機能があります。管理する AWS アカウントに対して予防的ガードレールを適用してガバナンスを利かせたり、子 AWS アカウントを生成する機能を使って、本番環境に影響を及ぼさない形で検証をすすめるなど、メリットがあります。

Control Tower の細かい部分や、運用が楽になる方法がよくわかってなかったこともあり、AWS が公式で出している英語のハンズオンをやってみました。
https://catalog.us-east-1.prod.workshops.aws/workshops/122b644d-03d6-4e2f-80dc-854c4a0f5bca/en-US

この記事では、上記ハンズオンを実施してみて、個人的に知らなったポイントを整理します。細かい Control Tower の操作手順などは、上記の URL を参考にしてみてください。

ハンズオンの章ごとに整理をしていきます。

# Landing Zone Set Up

https://catalog.us-east-1.p