大田区から発信するゆるゆる日記

主にITエンジニアに関する備忘録日記。たまに趣味も。何か不備があればコメント頂けると幸いです。Twitterアカウント https://twitter.com/ryuzan03

【AWS/Python】Lamdaオーソライザー リクエストパラメーター × IPアドレス制限(2/2)

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

概要

Lambdaオーソライザーでリクエストパラメーターベースの認証とIPアドレス制限を実装します。

AWSの公式サイトでは、IPアドレス制限はリソースポリシーで実装するのが一般的なようです。 API Gateway リソースポリシーが認証ワークフローに与える影響 - Amazon API Gateway

今回の記事は前回の続きになります。
LambdaオーソライザーでIPアドレス制限を実装していきます。

↓前回の記事はこちら↓
[:title]

IPアドレス制限の実装

IPアドレス制限を実装

前回作成したオーソライザー用のLambda関数に設定を追加します。

ConditionにIPアドレスを設定することも重要ですが、Resourceも重要です。

こちらの変数resourceに入っているAPIメソッドのARN(methodArn)がないと、APIGatewayがIAMポリシーを判定をしてくれません。

api-auth.py

~~~~~~~~~~~~~

def generate_policy(principalId, effect, resource):
    # if effect and resource:
    authResponse = {
        'principalId': principalId,
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [{
                'Action': 'execute-api:Invoke',
                'Effect': effect,
                'Resource': [resource],
 ++              'Condition': {
 ++               'IpAddress': {
 ++                  'aws:SourceIp': ['アクセス許可するIPアドレス']
 ++              }
 ++          }
            }]
        },
        'context': {
            'stringKey': 'stringval',
            'numberKey': 123,
            'booleanKey': True
        }
    }

    return authResponse

~~~~~~~~~~~~~

アクセス許可するIPアドレスは、CIDR表記も設定できるようです。



今後に向けて

EFSの記事が後回しになっているので、なんとかしたいな。。。



参考

素晴らしい記事に感謝致します。
API GatewayのCustom AuthorizerでIP制限する - Qiita
API Gateway リソースポリシーの例 - Amazon API Gateway

【AWS/Python】Lamdaオーソライザー リクエストパラメーター × IPアドレス制限(1/2)

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

概要

Lambdaオーソライザーでリクエストパラメーターベースの認証とIPアドレス制限を実装します。

AWSの公式サイトでは、IPアドレス制限はリソースポリシーで実装するのが一般的なようです。 API Gateway リソースポリシーが認証ワークフローに与える影響 - Amazon API Gateway

今回のIPアドレス制限は、何かしらの理由でリソースポリシーを使わない想定で、LambdaオーソライザーでIPアドレス制限を実装していきます。

Lamdaオーソライザー リクエストパラメーター実装

構成

AWS公式サイトを元に簡単な構成図を作成しました。
以下ページのリクエストパラメータベースを参考にしました。
API Gateway Lambda オーソライザーを使用する - Amazon API Gateway

Lambdaオーソライザー
Lambdaオーソライザー 構成図


リクエストベースの Lambda オーソライザー関数を作成

Lambdaコンソールでオーソライザー用の関数を作成します。

オーソライザー用の設計図が用意されているのですが、ランタイムがpython2.7であること、コードが多いことから、公式サイトのNode.jsのコードと設計図を参考に自作で作成しました。

Lambdaコンソールで「関数の作成→一から作成」を選択し、以下のコードを貼り付けてデプロイします。

api-auth.py

def handler(event, context):
    headers = event['headers']
    queryStringParameters = event['queryStringParameters']
    pathParameters = event['pathParameters']
    stageVariables = event['stageVariables']

    tmp = event['methodArn'].split(':')
    apiGatewayArnTmp = tmp[5].split('/')
    awsAccountId = tmp[4]
    region = tmp[3]
    restApiId = apiGatewayArnTmp[0]
    stage = apiGatewayArnTmp[1]
    method = apiGatewayArnTmp[2]
    resource = '/'
    if apiGatewayArnTmp[3]:
        resource += apiGatewayArnTmp[3]

    if headers['headerauth1'] == 'headerValue1':
        return generate_allow('me', event['methodArn'])
    else:
        return generate_deny('me', event['methodArn'])


def generate_policy(principalId, effect, resource):
    # if effect and resource:
    authResponse = {
        'principalId': principalId,
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [{
                'Action': 'execute-api:Invoke',
                'Effect': effect,
                'Resource': [resource]
            }]
        },
        'context': {
            'stringKey': 'stringval',
            'numberKey': 123,
            'booleanKey': True
        }
    }

    return authResponse


def generate_allow(principalId, resource):
    return generate_policy(principalId, 'Allow', resource)


def generate_deny(principalId, resource):
    return generate_policy(principalId, 'Deny', resource)

必要ない変数もあると思うので、要件に合わせて調整しください。


検証用のLambdaとAPIを作成

Lambdaのコンソール画面、及びにAPI Gatewayのコンソール画面からLambda関数とAPI(REST API)を作成します。

こちらの説明は割愛させていただきます。


オーソライザーを作成

API Gatewayコンソール画面の左帯にある「オーソライザー」からオーソライザーを作成します。

「Lambda関数」の項目には、先ほど作成したオーソライザー用のLamabda関数を選択します。

APIGateway オーソライザー
APIGateway オーソライザー
テストでオーソライザーがちゃんと作動しているか一度確認しておきましょう。


オーソライザーを検証用APIに設定

API Gatewayコンソール画面の左帯にある「リソース」からオーソライザーを検証用APIに設定します。

下記のメソッドリクエストをクリックします。

APIGateway リソース
APIGateway リソース 設定前

認可を先ほど作成したオーソライザーに設定する。

この時、2点注意しなければならない箇所があります。
1つ目は赤丸のチェックボタンをクリックしてください。
2つ目は左上にある「アクション」セレクトボタンから「APIのデプロイ」を実行してください。

APIGateway 設定
APIGateway 設定

すると、認可の部分が先ほど作成したオーソライザーに設定ができています。

APIGateway リソース 設定後
APIGateway リソース 設定後
更新が間に合わず、上手く設定ができていないことがあるので、都度ページの更新を行いながら作業を進めることをオススメします。


【確認作業】PostmanでAPIを叩く

下記の様にheadersにパラメーターを設定して、APIを叩きます。

Postman
Postman


おまけ

  • オーソライザーのテストで400エラー発生する
    拒否になっている場合が多いですが、たまにリクエストパラメーターを間違えているケースがあります。

  • オーソライザーのテストで500エラー発生する
    コードのミス、またはLambda関数の戻り値のIAMポリシーの構成を間違えているケースがあります。

  • SAMでも実装可能そう
    いつか挑戦してみたい。 Lambdaオーソライザーの例 - AWS Serverless Application Model



今後に向けて

次回はオーソライザー用のLambdaでIPアドレス制限を実装していきます。



参考

素晴らしい記事に感謝致します。
API Gateway リソースポリシーが認証ワークフローに与える影響 - Amazon API Gateway
API Gateway Lambda オーソライザーを使用する - Amazon API Gateway
Lambdaオーソライザーの例 - AWS Serverless Application Model

【AWS】Error: The AWS Access Key Id needs a subscription for the service【AWS CLI アカウント認証エラー】

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

※2020年11月21日 追記
今回のAWS CLIの認証エラーに関するベストプラクティスを見つけました!
もっと早くこの記事を見つけていれば...そしてAWSさすがだ...
EC2 インスタンスがロールの認証情報ではなく IAM ユーザーの認証情報を使用する理由

概要

SAMでAWSクラウドにデプロイした時に以下のエラーが発生しました。

$ sam deploy -g
---------------------省略---------------------
Looking for resources needed for deployment: Not found.
        Creating the required resources...

Error: Failed to create managed resources: An error occurred (OptInRequired) when calling the CreateChangeSet operation: The AWS Access Key Id needs a subscription for the service

$


AWS公式の解決策では解決できなかったので(単なる凡ミスだが)、ブログにまとめておきます。



結論

ローカルの環境変数にアクセスキーとシークレットキーを設定していたため、aws configureの設定が読み込まれていなかった。


解決への道順

まずはエラーをググってみた

ググったら早速それっぽいAWSの記事を発見。
AWS のサービスへのアクセスエラーの解決

AWSアカウントの認証かリソースへのアクセス権限がないかもとのこと。

親切にそれを確認してくれるURLが貼ってあったのでクリックしてみるが、特に問題はなさそう。

AWS認証設定がおかしいのかな?

次にAWS Access Key Idが間違っているのかなと思い、AWSコンソールからIAMのアクセスキーを作り直し、AWS CLIで設定を変更してみる。
設定ファイルと認証情報ファイルの設定 - AWS Command Line Interface

$ aws configure
AWS Access Key ID [None]: 作り直したアクセスキー
AWS Secret Access Key [None]: 作り直したシークレットキー
Default region name [None]: ap-northeast-1.
Default output format [None]: json


念のために、設定ファイルも確認してみる。

$ cd ~/.aws
$ cat credentials
[default]
aws_access_key_id = 作り直したアクセスキー
aws_secret_access_key = 作り直したシークレットキー


こちらも特に問題なさそう。

しかし、再度デプロイし直しても同じエラーがでる。

AWSに問い合わせてみた

運営側のAWSアカウントの認証がおかしいのかなと思い問い合わせてみた。

察しが良い方は既にお気付きかと思いますが、開発に関する問い合わせは有料プランで問い合わせてくださいと返事が来ました。

ルール無視してすみませんでした。さすがはしっかりしている。

設定データを表示したら気付いた謎のenvの文字

どうしようもなく困ったなーと思って設定データを見ていたら、アクセスキーの末尾が違うことに気付きました。

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************ABCD env    
secret_key     ****************ABCE env    
    region           ap-northeast-1      config-file    ~/.aws/config


そしてさらに気付く謎のenvの文字。

...環境変数イジってんな!!!

本来であれば下記のような表記になるはずでした。

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************EFGH shared-credentials-file    
secret_key     ****************EFGI shared-credentials-file    
    region           ap-northeast-1      config-file    ~/.aws/config


どうやら私は過去にローカルの環境変数AWSのアクセスキーやシークレットキーを設定していたみたいで、それが邪魔をしていました。
なので、bash_profileからAWSの設定を削除しました。

$ vim ~/.bash_profile


そしてターミナルを立ち上げ直し、再度デプロイしたらエラーが発生することなくデプロイできました。


今後に向けて

解決するのに時間がかかりすぎてしまいました。。。 これからも精進していきます。

【AWS】SAMでLambda,EFS,RDS,S3,ApiGateway連携アプリケーションを作成(1/2)

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

概要

今回はSAMでLambda,EFS,RDS,S3,ApiGateway連携アプリケーションを作成していきます。

SAMでベースのアプリケーションを作成してから、各リソースとの連携を実装していこうと思います。
少し長くなりそうなので、分割して投稿します。

今回は以下のサイトを参考に、ベースとなるアプリケーションを構築していきます。
チュートリアル Hello World アプリケーションの導入 - AWS Serverless Application Model


SAMでHello World

今回もmacOSで実装していきます。

AWS SAM CLIのインストール

以下のサイトを参考にAWS SAM CLIをインストールします。
インストール方法は本題からブレるので割愛します。
macOS への AWS SAM CLI のインストール - AWS Serverless Application Model

  1. AWS アカウントの作成
  2. IAM アクセス許可の設定
  3. Docker をインストールします。注意 Dockerは、アプリケーションをローカルでテストするための前提条件です。
  4. Homebrew をインストールします。
  5. AWS SAM CLI のインストール


Sampleプロジェクトのベース作成

sam initで簡単にリポジトリのベースを作成することができます。

bash

$ sam init
Which template source would you like to use?
    1 - AWS Quick Start Templates
    2 - Custom Template Location
Choice: 1

Which runtime would you like to use?
    1 - nodejs12.x
    2 - python3.8
    3 - ruby2.7
    4 - go1.x
    5 - java11
    6 - dotnetcore3.1
    7 - nodejs10.x
    8 - python3.7
    9 - python3.6
    10 - python2.7
    11 - ruby2.5
    12 - java8.al2
    13 - java8
    14 - dotnetcore2.1
Runtime: 2

Project name [sam-app]: sam-app

Cloning app templates from https://github.com/awslabs/aws-sam-cli-app-templates.git

AWS quick start application templates:
    1 - Hello World Example
    2 - EventBridge Hello World
    3 - EventBridge App from scratch (100+ Event Schemas)
    4 - Step Functions Sample App (Stock Trader)
    5 - Elastic File System Sample App
Template selection: 1

-----------------------
Generating application:
-----------------------
Name: sam-app
Runtime: python3.8
Dependency Manager: pip
Application Template: hello-world
Output Directory: .

Next steps can be found in the README file at ./sam-app/README.md


これでsam-appのリポジトリが以下の構成で作成されているはずです。

 sample-sam-app/
   ├── README.md
   ├── events/
   │   └── event.json
   ├── hello_world/
   │   ├── __init__.py
   │   ├── app.py            #Contains your AWS Lambda handler logic.
   │   └── requirements.txt  #Contains any Python dependencies the application requires, used for sam build
   ├── template.yaml         #Contains the AWS SAM template defining your application's AWS resources.
   └── tests/
       └── unit/
           ├── __init__.py
           └── test_handler.py



ビルド

sam-appプロジェクトをビルドするために、sam buildを実行します。
プロジェクトのディレクトリに移動してから実行しましょう。

bash

$ cd sam-app
sam-app $ sam build
Building codeuri: hello_world/ runtime: python3.8 metadata: {} functions: ['HelloWorldFunction']
Running PythonPipBuilder:ResolveDependencies
Running PythonPipBuilder:CopySource

Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

Commands you can use next
=========================
[*] Invoke Function: sam local invoke
[*] Deploy: sam deploy --guided


ビルドに成功すると、sam-appディレクトリ直下に以下のファイルが作成されます。

.aws-sam/build
.aws-sam/build/template.yaml


sam-appプロジェクトを作成した際に指定したPythonのバージョンの設定を行っていないと、buildでエラーが発生します。その際は別途設定が必要になります。



デプロイ

遂にAWSクラウドにsam-appプロジェクトをデプロイします。
デプロイもとても簡単で、sam deployコマンドを実行するだけです。

今回は初回なので、ガイド付き(--guide, -g)でデプロイしてみます(初回はガイド付きじゃないとsam deployコマンドは実行できないみたい)。

bash

$ sam deploy -g

Configuring SAM deploy
======================

        Looking for config file [samconfig.toml] :  Not found

        Setting default arguments for 'sam deploy'
        =========================================
        Stack Name [sam-app]: sam-app
        AWS Region [us-east-1]: ap-northeast-1
        #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
        Confirm changes before deploy [y/N]: y
        #SAM needs permission to be able to create roles to connect to the resources in your template
        Allow SAM CLI IAM role creation [Y/n]: Y
        HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y
        Save arguments to configuration file [Y/n]: Y
        SAM configuration file [samconfig.toml]: 
        SAM configuration environment [default]: 

        Looking for resources needed for deployment: Not found.
        Creating the required resources...
        Successfully created!

                Managed S3 bucket: aws-sam-cli-managed-default-samclisourcebucket-1e3i2
                A different default S3 bucket can be set in samconfig.toml

        Saved arguments to config file
        Running 'sam deploy' for future deployments will use the parameters saved above.
        The above parameters can be changed by modifying samconfig.toml
        Learn more about samconfig.toml syntax at 
        https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html
Uploading to sam-app/1696cfa0a6a173b9162e5a  546199 / 546199.0  (100.00%)

--------------省略--------------

Successfully created/updated stack - sam-app in ap-northeast-1

これでSAMを使ったデプロイが完了しているはずです。

実際に確かめてみます。
まずはCloudFormationから。 f:id:ryuzan03:20201120103904p:plain
大丈夫そうですね。

次はLambda。 f:id:ryuzan03:20201120103858p:plain
こちらも大丈夫そうです。

他のリソースの確認は割愛しますが、無事にSAMでデプロイができました。

ちなみにSAMでの課金はありませんが、今回立ち上げたリソースの中には放っておくと課金されるものがあります。 今後使用しないような場合はCloudFormationのコンソール画面からスタックを削除しておいて方が良さそうです。
S3バケットは一緒には削除されないようなので、不要であればS3のコンソール画面から削除しておきましょう。


用語集

Amazon EventBridge

参考資料: Amazon EventBridge とは - Amazon EventBridge よくある質問 - Amazon EventBridge | AWS

CloudWatch Eventsを拡張するサービス。CloudWatch Eventsと同じサービスを使える他、独自のアプリケーションとAWSリソースを簡単に接続しデータのやりとりができるようにします。

Scratch

参考資料: Scratch - Imagine, Program, Share

プログラミング言語。子供向けコンテンツの作成に特化しており、子供自身がゲームやアニメーションなどのコンテンツをプログミングすることで、創造的に考える力が身に付くとされている。

template.yaml

参考資料: チュートリアル Hello World アプリケーションの導入 - AWS Serverless Application Model

SAMアプリケーションのAWSリソースを定義するテンプレート。

hello_world/app.py

参考資料: チュートリアル Hello World アプリケーションの導入 - AWS Serverless Application Model

Lambdaハンドラロジック部分。

hello_world/requirements.txt

参考資料: チュートリアル Hello World アプリケーションの導入 - AWS Serverless Application Model

Pythonの依存関係(サードパーティ)が定義されている。アプリケーションの依存関係構築に使用されるので、かなり重要。 Pythonをvendorとするならば、vendor/pythonディレクトリを作成してファイル移動してもいいかも。

samconfig.toml

参考資料: AWS SAM CLI構成ファイル - AWS Serverless Application Model

tomlは設定ファイルを定義するための拡張子です。
AWS AWS CLIでデプロイする時に必要な設定情報が書き込まれるファイルです。
これまた重要。


今後に向けて

次回は本題であるLambda,EFS,RDS,S3,ApiGatewayが連携しているアプリケーションを構築していきます。


【AWS】Lambda関数でEFSにCSVファイルを生成する

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

概要

今年の6月にLambda関数がEFSをマウントできるようになったのは、既に皆さんは知られているかと思います。

自分は恥ずかしながらつい先日知りました←

AWSブログを参考にしてハンズオンしていたのですが、少々詰まりましたので、CSVファイル生成方法と合わせてブログにまとめます。


LambdaでEFSにCSVファイルを生成する

セキュリティグループ作成

EFSやLambda関数を作成する前に、以下のURLからセキュリティグループを作成しておきます。
https://ap-northeast-1.console.aws.amazon.com/vpc/home?region=ap-northeast-1#securityGroups:

セキュリティグループはEFS用とLambda関数用を作成します。
設定は以下の表を参考にしてください。

名前,説明,タグ VPC インバウンドルール アウトバウンドルール
Lambda関数用セキュルティグループ 任意 デフォルト なし 全てのトラフィック
EFS用セキュリティグループ 任意 デフォルト タイプ:NFS,プロトコル:TSP,ポート範囲:2049,ソース:上記Lambda用デキュリティグループ 全てのトラフィック


EFSファイル作成

以下のURLからEFSファイルを作成します。
https://ap-northeast-1.console.aws.amazon.com/efs/home?region=ap-northeast-1#/file-systems

設定は以下の表を参考にしてください。

カテゴリー
名前 任意
VPC デフォルト
ルートディレクトリパ /file
ユーザーID 1001
グループID 1001
所有者ユーザーID 1001
所有者グループID 1001
アクセス許可 755
タグ 任意
マウントターゲット 全てのアベイラビリティーゾーンのセキュリティグループを上記で作成したEFS用セキュリティグループに変更


Lambda関数作成

以下のURLからLambda関数を作成する。
ランタイムですが、今回はPython3.8を選択します。
https://ap-northeast-1.console.aws.amazon.com/lambda/home?region=ap-northeast-1#/functions

IAMロールにポリシーをアタッチする

Lambda関数作成時に自動的に生成されるIAMロールに、ポリシーをアタッチします。

先ほど作成したLambda関数コンソールでアクセス権限タブを選択し、実行ロールカテゴリーからIAMロールのページに移動します。

移動後のベージのアクセス権限から以下のポリシーをアタッチします。

  • AmazonElasticFileSystemClientReadWriteAccess
  • AWSLambdaVPCAccessExecutionRole


Lambda関数のVPCを編集

Lambda関数のコンソールからVPCを編集します。

設定は以下の表を参考にしてください。

カテゴリー
VPC デフォルト
サブネット EFSのネットワークのサブネットを全て選択
セキュリティグループ Lambda関数用のセキュリティグループを選択


Lambda関数にファイルシステムを追加

Lambda関数のコンソールからファイルシステムを追加します(EFSをマウントします)。

設定は以下の表を参考にしてください。

カテゴリー
EFSファイルシステム 上記で作成したEFSを選択
アクセスポイント 上記で作成したEFSのアクセスポイントを選択
マウントパス /mnt/file


Lambda関数をデプロイ

Lambda関数のコンソールで以下のコードの入力が終われば、デプロイをしてください。

EFSにCSVファイルを作成するコード

import os
import fcntl
import csv

# 変数にLambda関数でマウントしたパスを格納する
FILE_PATH = '/mnt/file'

def lambda_handler(event, context):
    method = event['requestContext']['http']['method']
    name = event['body']

    file_path = u'%s/%s' % (FILE_PATH, name)
    csv_path_name = u'%s/%s.csv' % (file_path, name)

    try:
        if method == 'POST':
            message = add_csv(file_path, csv_path_name)
        elif method == 'GET':
            message = get_text(csv_path_name)
        else: 
            message = 'not method'

    except:
        message = 'error handler'

    return message

def add_csv(filepath, csvname):
    os.makedirs(filepath, exist_ok=True)

    try:
        with open(csvname, 'w') as f:
            fcntl.flock(f, fcntl.LOCK_EX)
            writer = csv.writer(f)
            writer.writerow(['aa', 'aa'])
            message = 'create csv file '
            fcntl.flock(f, fcntl.LOCK_UN)

    except:
        message = 'error add_csv'

    return message

def get_text(csvname):
    try:
        with open(csvname) as f:
            fcntl.flock(f, fcntl.LOCK_SH)
            text = f.read()
            fcntl.flock(f, fcntl.LOCK_UN)

    except:
        text = 'error get_text'

    return text


トリガーを追加

Lamda関数のコンソールでAPI Gatewayのトリガーを追加します。

「トリガーを追加」をクリックしたら、API Gatewayを選択します。
その他の設定は以下の表を参考にしてください。

カテゴリー
API APIを作成する
APタイプ HTTP API
セキュリティ オープン


ターミナルから以下などを実行

bash

$ curl -X POST -H "Content-Type: text/plain" -d 'CSVファイル名' 先ほど作成したAPI Gatewayのエンドポイント
$ curl GET 先ほど作成したAPI Gatewayのエンドポイント



今後に向けて

Lambda関数を使ってS3のデータをEFSに移動したりしてみたいです。


参考

素晴らしい記事に感謝致します。
新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda | Amazon Web Services ブログ
AWS Lambda から Amazon EFS へのアクセス - Qiita

指定したサイズのダミーファイルを生成

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

IT業界では常識かもしれませんが、テスト用に指定されたサイズのファイルが欲しいかった時に悩んだのでブログにまとめておきます。

ちなみにMac向けのブログになります。

ダミーファイルの生成

コマンド

$ mkfile 【サイズ】【ファイル名】


サイズは単位と合わせて指定します。

  • b(Byte)
  • k(KB)
  • m(MB)
  • g(GB)


$ mkfile 15m dummy.csv

【AWS】アカウントのセキュリティ

※下記の内容に不備がありましたら、コメント頂けると幸いです。また、下記の内容をご使用頂ける場合は自己責任でお願いします。

概要

AWSはとても便利な反面、第三者からも狙いやすいです。極論、パソコンとネットワークが整っていれば、勝手にAWSを操作することができます。

しかし、しっかりと対策を講じていればそのリスクを減らすことができるので、セキュリティ対策は万全にしておきしょう。

このブログで書かれていることを実行すれば100%大丈夫というわけではないので、参考程度に見ていただき、各々にあったセキュリティ対策を実施するのがいいと思います。

IAMのダッシュボードに書かれているベストプラクティスを参考にされるのもいいかもしれません。
https://console.aws.amazon.com/iam/home?region=ap-northeast-1#/home

アカウントのセキュリティ

実施内容

今回は以下の三つのセキュリティ対策を行います。

  • ユーザアカウントを使う
  • 多要素認証の有効化
  • AWS Cloud Trailの有効化


ユーザアカウントを使う

最初に作成したAWSアカウントはルートアカウントと呼ばれ、なんでもできてしまうアカウントになります。それを使い続けるのはセキュリティ的に非常にマズいので、極力使わないようにします。

ルートアカウントは権限を付けた別のユーザを作成することが可能なので、今後はそのユーザを使ってAWSのサービスを触っていきます。

作業内容は割愛しますが、以下のことを行いました。

  • ユーザ作成でグループを作ってユーザを追加してAdministratorAccess権限を付与
  • 作ったグループの「アクセス権限の追加」から、「既存のポリシーを直接アタッチ」を選択し、IAMユーザーという権限を付与
  • アカウント設定からパスワードポリシーを変更

多要素認証の有効化

少し前に多要素認証機能が実装されていないサービスが問題になりましたよね。

AWSでは多要素認証機能が実装されているので、なりすましを防ぐためにも多要素認証を有効化しておきます。

作業内容は割愛しますが、以下のことを行いました。

AWS Cloud Trailの有効化

AWS Cloud Trailを有効化することでアクティビティログを記録することができます。万が一、誰かに勝手にAWSを使われた時も誰が使ったのか分かるようになります。

またCloud Watchと連携させると、Cloud Trailから送信されてくるアクティビティログを元に、Cloud WatchがLambdaなどに何らかの操作を実行させることもできるようになります。

作業内容は割愛しますが、以下のことを行いました。

  • 証跡の作成
  • Cloud Watchの設定


これでアクティビティログやAPI実行ログをS3に記録することができました。注意点としては、S3はデータが貯まると有料になるので、有料になるのが嫌な方は、定期的なデータの削除やS3に記録しないなどの対策が必要です。

今後に向けて

次回から本格的にサービスを触っていく予定です。