開発日誌
更新日 (2021/10/15)
AWS 必須セキュリティー対策 GuardDuty

はじめに

今回は簡単にセキュリティー対策のできるAWSの脅威検知サービスであるAmazon GuardDutyを紹介したいと思います。オンプレミスの時代と比べるとAWSなどのパブリッククラウドでは簡単にサーバーを立てることができとても便利な時代になりました。気軽に利用できるためセキュリティー対策ができてなくマイニングにされたり、高額請求されたなどの話はよく耳にします。


AWS ではセキュリティー対策として下記のような様々なサービスを提供しております。今回はこの中でも簡単始めることのできるGuardDutyについて説明させていただきます!

  • ■ GuardDuty
  • ■ Amazon Macie
  • ■ AWS License Manager
  • ■ Config
  • ■ CloudTrail
  • ■ AWS Security Hub
  • etc....

Amazon GuardDutyとは

AWSアカウント、ワークロード、および Amazon S3 に保存されたデータを保護するために、悪意のあるアクティビティや不正な動作を継続的にモニタリングする脅威検出サービスです。悪意のある操作や不正な動作を継続的にモニタリングしてくれます。

機械学習、異常検出、および統合された脅威インテリジェンスを使用することで、潜在的な脅威を識別し、優先順位を付けてくれます。

料金

Amazon GuardDutyの利用料金はAWS CloudTrail 管理イベント数、AWS CloudTrail S3 データイベント数、VPC フローログと DNS ログのデータ量に対して課金が行われます。
Amazon GuardDuty の料金


計算はしづらいですがかなり安いです!! また、1日あたりの合計推定コストはGuardDutyのコンソール画面で簡単に確認することができます。

Amazon GuardDutyの設定

GuardDutyはボタン1つで有効化することができ継続的にモニタリングをしてくれるため利用者側としては特に何もする必要はありません。しかし、注意していただきたいのはGuardDutyは攻撃や異変を検知するだけでその後の対応・対策はしてくれません。
また、Cloudwatchevent と SNSを連携することにより異変検知したらセキュリティー担当者へメールを送信させることができます。


手順はすごく簡単です。

  • 1. Amazon GuardDutyを有効化にする
  • 2. SNSトピックを作成する
  • 3. Cloudwatchイベントを作成する
これでAmazon GuardDutyが検知したときにメールを送信してくれるようになります。

まとめ

Amazon GuardDutyはボタン一つで有効化することができ利用料金も比較的安いので全アカウント全リージョンで有効にすべきだと思います。
また、まだ利用されていない方は最初の30日間は無料で利用できるので是非試してみてください!
サーバ運用とWebサイト運用・システム運用などが業者が別々で問題解決が困難、もしくは業務をワンストップでお願いしたいなどございましたら遠慮なくご相談ください。
サーバの設計や構築のみなどミニマムな業務からも承ってますので是非コムデへご相談ください。




開発日誌
更新日 (2021/09/06)
AmazonLinux2 で lego を使い Route53 認証でサーバ証明書を取得する
AmazonLinux2  lego を使いRoute53 を使った DNS 認証サーバ証明書を取得する手順す

※lego・・・Go製のCLIツールです。

前提条件
AWS EC2 AmazonLinux2
IAM ポリシーを作成する
<INSERT_YOUR_HOSTED_ZONE_ID_HERE> 部分は Route53 の管理画面該当 DNS Zone 情報から取得

	{
	    "Version": "2012-10-17",
	    "Statement": [
	        {
	            "Effect": "Allow",
	            "Action": [
	                "route53:GetChange",
	                "route53:ListHostedZonesByName",
	                "route53:ListResourceRecordSets"
	            ],
	            "Resource": [
	                "*"
	            ]
	        },
	        {
	            "Effect": "Allow",
	            "Action": [
	                "route53:ChangeResourceRecordSets"
	            ],
	            "Resource": [
	                "arn:aws:route53:::hostedzone/<INSERT_YOUR_HOSTED_ZONE_ID_HERE>"
	            ]
	        }
	    ]
	}
 
インストールする
AmazonLinux2 lego をインストール
mkdir tmp
cd tmp
wget https://github.com/go-acme/lego/releases/download/v3.7.0/lego_v3.7.0_linux_amd64.tar.gz
tar zxvf lego_v3.7.0_linux_amd64.tar.gz
mv lego /usr/local/bin/
chmod 755 /usr/local/bin/lego
chown root:root /usr/local/bin/lego
サーバ証明書を取得する
lego を使い、サーバ証明書を取得。 

lego --accept-tos \
--path=/etc/letsencrypt \
--email="email@example.com" \
--dns="route53" \
--domains="www.example.com" \
run
サーバ証明書を更新する
サーバ証明書を更新

lego --accept-tos \
--path=/etc/letsencrypt \
--email="email@example.com" \
--dns="route53" \
--domains="www.example.com" \
renew \
--days 30



開発日誌
更新日 (2021/09/06)
AWS CDKに感動した話

CDKとは

AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。 出展:https://aws.amazon.com/jp/cdk/
AWS CDK(以降CDKに省略)はソースコードでインフラ構築・管理を行うフレームワークです ソースコードによるインフラ構築であればCloudFormationも候補に上がりますが、 CloudFormationの場合、ソースコードとしてjsonファイルもしくはyamlファイルに論理名の紐付けなど細かく記載する必要があります。 しかし、CDKの場合はTypeScritp、Python、Javaなど普段使い慣れたプログラム言語を使用することができ、細かい設定はCDKが吸収してくれるため、実装負荷が大変少ないです。

CDKで変わったインフラ構築

これまではAWSのコンソール上からインフラを構築していました。 しかし、コンソール上から手作業でインフラを用意するのは下記のこともあり”とても”大変です。
  • 構築に時間がかかる インフラ構築にはVPC、EC2、RDSなどさまざまなものを構築する必要がある それぞれ人の手で行うと一つの環境を作るのに数時間掛かってしまう
  • 構築ミスが発生 人の手による作業なので当然構築ミスも発生する 当然、ミスが出た際の問題解決に時間が割かれてしまう
  • 殆ど同じ環境を作らなければいけない苦行 web開発では通常、 PROD,STG,DEV+α環境と多くの環境を作ることが求められる。 そのため、同じ作業を複数回行わなければならず、マラソンをやっているような気持ちになる ※こちらとても私的な意見です
上記の問題はCDKを使うことで大幅に改善される

CDKのソースコードがあれば短時間でインフラ構築が完了する

CDKではソースコードさえあればターミナル上で片手で数えられるコード入力のみでインフラの構築が済んでしまう   例えば、下記のコマンド一発でソースコード記載のインフラ構築ができてしまいます。
cdk deploy --all
複数のインフラ構築作業が圧倒的に楽になりますね。

ミスが少なくて済む

ソースコードを読み込んでインフラ構築を行うため、いつでも同じ環境を作成することができる 属人化を防ぐ意味でも良いですね また、CDKはライブラリを使用するため、エディタの補完機能を使用することができ、ソースコード作成時のミスも少なくて済みます。

バージョン管理ができる

CDKはソースコードでインフラ構築ができるため、gitなどでバージョン管理ができます 下記のコマンド一発でソースコード記載のインフラ環境と実際にインフラ環境の差分が表示されます
cdk diff

CDKはいいぞ

CDKは便利の一言です   一度ソースコードを組んでしまえば同じ環境をいくらでも量産できるので、ちょっと新しい環境を作って試してみたいことがあった際に簡単にスクラップ&ビルドを行えてしまいます。 開発速度の向上が期待できますね。 また、インフラ構築自体はコマンド一発で出来上がってしまうので、属人化しないのが非常に良いですね。極論を言ってしまえば、ソースコードさえあればサルでもインフラ構築ができてしまいます。   問題のソースコードの実装自体は慣れさえすれば簡単です。特にAWSを使用したことがある方であれば構築時の設定と同じ内容を記載すれば良いので、すぐに感覚が掴めると思います。   一度触ってしまったらコンソール上でのインフラ構築には戻れません CDKにはそれほどの魅了が詰まっています 初心者用にAWSがワークショップを作ってくれているのも敷居が低くて大変良いです 皆さんも是非機会がありまたら触ってみてください!



開発日誌
更新日 (2021/09/06)
Autoscaling起動時にEIPをアタッチさせる
 外部APIとの接続があるときautoscalingで起動されたec2にも固定IPをつけたくなることがあると思います。その場合はNATゲートウェイを使うのがベストプラクティスだそうです。しかし、NATゲートウェイは意外と料金が高くつくので今回はEIPをAutoscaling時に自動でアタッチさせる方法を試してみます。 

実装手順

  1.  1. アタッチさせるEIPを事前にプールしておく
  2.  2. IAMポリシーの作成
  3.  3. シェルスクリプトの設定
 
  1. 1. アタッチさせるEIPを事前にプールしておく
    今回はこちらのIPを使っていきます。概要欄に割り当てIDが表示されているのでコピーしておきます。
  1. 2. IAMポリシーの作成
   EC2 APIの多くはリソースレベルでのアクセス許可制限が可能ですがすべてのEC2アクションでリソースを指定できるわけではないそうです。そして今回のアクションがリソースレベルのアクセス許可がサポートされていないアクションだそうです。。。       スクリプトを貼り付けて実行するだけでは権限が足りないようでこんなエラーが出ます。
An error occurred (UnauthorizedOperation) when calling the DescribeAddresses operation: You are not authorized to perform this operation.
{
    "Version": "2012-10-17",
    "Statement": [
        {
           "Sid": "ec2eip",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateImage",
                "ec2:CreateSnapshot",
                "ec2:Describe*",
                "ec2:DescribeInstances",
                "ec2:DescribeAddresses",
                "ec2:AssociateAddress"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "ec2",
            "Effect": "Allow",
            "Action": [
                "ec2:RebootInstances",
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": [
                "arn:aws:ec2:ap-northeast-1::instance/"
            ]
        }
    ]
}
なのでAutoscalingのEC2にアタッチするポリシーを作る必要があります。ポリシーを作成してAutoscalingで利用するロールにアタッチします。  
  1. 3. シェルスクリプトの設定
 インスタンスの起動時にスクリプトを実行させるためユーザーデータの設定に下記のコードを設定します。
    ・ Autoscaling起動設定の作成 ->追加設定 -> ユーザーデータ
#!/bin/bash

yum install jq -y

# EIPの割り当てID
eip_alloc_ids="eipalloc-07fad2290f8915762"
export AWS_DEFAULT_REGION=ap-northeast-1 instance_id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

available_alloc_id=$(aws ec2 describe-addresses --allocation-ids ${eip_alloc_ids} | jq -r '[.Addresses[] | select(.InstanceId == null)][0] | .AllocationId')

echo $available_alloc_id

aws ec2 associate-address --instance-id ${instance_id} --allocation-id ${available_alloc_id}
■まとめ
 今回はAutoscaling起動時のec2のIPを固定化するためにEIPをアタッチさせました。EIPは月に300円程度なのでNatゲートウェイを使うよりも安く収まります。しかし、Natゲートウェイを利用したほうがec2をプライベートサブネットに置くことができるなどのメリットがあるのでNatゲートウェイの利用をおすすめします。

■参考
https://aws.amazon.com/jp/blogs/security/demystifying-ec2-resource-level-permissions/?nc1=h_ls
https://dev.classmethod.jp/articles/choose-eip-from-addresspool/



開発日誌
更新日 (2021/07/26)
AWSのコスト削減・AWS Instance Schedulerの使い方 
 AWSは従量課金制のため手軽にサービスを利用をしていくことができとても便利ですが料金の全体像が見えにくいため想定以上に料金がかかってしまうことが多いかと思います。なので今回は運用時のコスト削減方法を紹介したいと思います!  AWSのコスト削減にはスポットインスタンスやリザーブドインスタンスなどが有名ですが今回はあまり知られていないAWS Instance Schedulerについて説明します。  

AWS Instance Schedulerによってできること

 Amazon EC2および RDSインスタンスの開始スケジュールと停止スケジュールを設定して、AWS リソースコストを管理することができます。 また、使用されていないリソースを停止し、キャパシティーが必要なときにリソースを開始することで、運用コストを削減するのに役立ちます。例えば、企業は本稼働環境で AWS Instance Scheduler を使用して、毎日営業時間外にインスタンスを自動的に停止できます。現在すべてのインスタンスを完全に使用したままにしている場合、このソリューションによってインスタンスの使用率が低下し、設定されたスケジュールに基づいて全体的なコストが削減される可能性があります。    簡単にまとめると会社の業務時間内(9:00~18:00)のみインスタンスを稼働させ業務時間外はインスタンスを止め費用の削減をすることができ、起動と停止の作業をを自動でやってくれます !    上記の構成図の通り、Instance SchedulerはAWSが提供するサービスそのものではなく各サービスの組み合わせでの総称なため使ったことのない人も多いと思いますがコストを削減していく上でかなり重要なサービスです。ただし、注意してもらいたいのがCloudformationで作成したLamdbaなどのサービスコストが月に$5ほどかかります。   こちらの構成図を1から作るのはかなり面倒ですがすでに公式でCloudformationのテンプレートが用意されているので簡単に作成することができます!!

Instance Schedulerの設定手順

1. Cloudformationの設定

  • 下記のurlを開き画面右側にある ”awsコンソールで起動する” を押す
https://aws.amazon.com/jp/solutions/implementations/instance-scheduler/ 最初はバージニアリージョンになるので正しいリージョンへ変更する これでcloudformationの設定は完了です。CloudFormation によって、 下記のResourcesが作成されます。 ・Lambda  ・DynamoDB ・IAM Policy ・EventBridge Rule ・KMS ・SNS

2. スケジュールの設定

コンソール画面からDynamodbのページへ行きます。cloudformationの設定がうまく出来ていれば3つのテーブルが作成されているはずです。スケジュールの設定はDynamodbのテーブルからできます。 instance-scheduler-ConfigTableを開き ①Instance−scheduler−ConfigTableを選択 ②name: office-hoursを選択->アクション->編集 ③name: uk-office-hoursを選択-> アクション-> コピー これでスケジュールの設定は以上です。あとは裏でLambdaがいい感じに対応してくれます!

3.インスタンスにタグ付け

あとはインスタンス(EC2,RDS)に 特定の Tag をつけるだけです。Tagをもとに自動起動・停止が動作します。

まとめ

かなり駆け足でしたが簡単にAWS Instamce Schedulerの使い方について説明しました。 Instamce Schedulerは今回説明した機能だけではなくインスタンスサイズのアップグレードの変更などもできます。 開発環境やStaging環境のコスト削減していくにはおすすめなサービスだと思います。 参考 https://d1.awsstatic.com/Solutions/ja_JP/instance-scheduler.pdf



開発日誌
更新日 (2021/07/23)
Dynamodbを可視化グラフ化
Dynamodb上のデータをグラフ化するにはBIツールであるAmazon QuickSightやElasticsearchなどのサービスがあります。しかし、Amazon QuickSightでグラフ化するにはLambdaを使ってDynamoDBのデータをCSVに変換しS3に格納したりする必要があるため面倒です。なので今回はcloudwatchを使ってデータをグラフ化(可視化)したいと思います。

設定手順

①Dynamodbテーブルの作成

今回はデバイスの温度を管理するテーブルを作成し、データをグラフ化したいと思います。   - テーブル名: SensorTable - プライマリキー: SensorID  数値型 - ソートキー: Time  文字列型   作成したSensorTableにデータを入れます。 ■Dynamodb Streamの有効化 Dynamodb StreamとはDynamoDBに対する項目の追加、変更、削除をイベントとして検出できる機能です。
テーブルで DynamoDB Streams を有効にした場合、書き込む AWS Lambda 関数にストリーミングの Amazon リソースネーム (ARN) を関連付けることができます。テーブルの項目が変更されると、新しいレコードがテーブルのストリーミングに直ちに表示されます。AWS Lambda はストリーミングをポーリングし、新しいストリーミングレコードを検出したときに Lambda 関数を同期的にコールします。 公式より引用

②Lambdaの作成

   - 関数名(今回はput_cloudwatch)  - ランタイム Python 3.8 画像4 これでLambda関数が作成されたと思います。関数を作成すると自動でロールが作成されます。しかし、このロールはCloudwatch logsの権限しかついていないためポリシーをつけ加えます。 下記2つのポリシーをアタッチする - CloudWatchFullAccess - AWSLambdaDynamoDBExecutionRole トリガーの追加 最後にソースコードをDeployすればDynamodbをトリガーとするLamabda関数の完成です。  
import json
import boto3

cloudwatch = boto3.client('cloudwatch')

def lambda_handler(event, context):
    
    SensorID = event['Records'][0]['dynamodb']['Keys']['SensorID']['N']
    Temperature = event['Records'][0]['dynamodb']['NewImage']['Temperature']['N']
    # print(Temperature)
    # print(SensorID)

    try:
        cloudwatch.put_metric_data(
        MetricData = [
            {
                'MetricName': 'SensorTable',
                'Dimensions': [
                    {
                        'Name': 'SensorID',
                        'Value': f'SensorID-{int(SensorID)}'
                    },
                ],
                'Unit': 'Count',
                'Value': int(Temperature)
            },
        ],
        Namespace = 'SensorTable'
        )
        
    except Exception as e:
        print('Error: Dynamodb error', e)
        print(e)

  SensorTableにテーブルにデータを入れるとcloudwatchカスタムメトリクスが作成されているはずです。エラーが出た場合はCloudwatch logsを確認してみてください。   まとめ 今回はDynomodb上のデータをcloudwatchを利用してグラフを作成しました。cloudwatchで作成したことによりアラームの作成やほかサービスとの連携が簡単にできると思います。しかし、cloudwatchの料金は意外と高いため注意が必要です!  
参考
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.Lambda.Tutorial.html  
cloudwatchの料金
https://aws.amazon.com/jp/cloudwatch/pricing/?nc1=h_ls