やーまんぶろぐ

気が向いた時にだけ書くブログ

AWS Well-Architected Lens – Serverless Applications まとめ セキュリティ編

AWS

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編、セキュリティ編、信頼性編、パフォーマンス編、コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVSEC 1：サーバーレスAPIへのアクセスをどのように承認し、認証しますか？

SERVSEC 2：Lambda機能がアクセスできるAWSサービスについて、どのように境界を強制していますか？

  • Lambda関数がアクセスできるものに関しては、最小特権アクセスに従うこと、指定された操作を実行するために必要なものだけを厳密に許可することが推奨される。
  • API Gateway APIキー機能はセキュリティのメカニズムではなく、メータリングのために使用される。APIキーごとの使用状況を追跡することができる。
    • https://image.slidesharecdn.com/20161116awsblackbeltapigateway-161116105747/95/aws-black-belt-online-seminar-2016-amazon-api-gateway-43-638.jpg?cb=1479431239
  • カスタムオーソライザを使用する場合、クレデンシャル情報や機密データをクエリ文字列のパラメータやヘッダーに使用することはお勧めしない。
  • 複数Lambda関数でIAMを共有することは、最低特権アクセスに違反する可能性があるので注意。

SERVSEC 3：サーバーレスのアプリケーションログをどのように分析していますか？

  • CloudWatchのメトリクスフィルタを利用すると、サーバレスアプリケーションの標準出力を、正規表現のパターンマッチングによってカスタムメトリクスに変換して件数をグラフ化することが可能です。
    • さらに、アプリケーションのカスタムメトリクスに基づいてCloudWatchアラームを作成することで、アプリケーションの動作を素早く把握できる。
  • AWS CloudTrailログは、監査とAPI呼び出しの両方に使用する必要がある。
  • トラブルシューティングの際に、ステージ全体ではなく個々のメソッドに対してAPIGatewayログを有効にすることを検討する。
  • サーバーレスアプリケーションの設計によっては、機密データが含まれている場合があるので注意する。
  • Lambda関数のコード内でCloudWatchに対するAPI呼び出しを行うと、不要なデータがログに取り込まれる可能性がある。
  • API Gatewayはリクエスト/レスポンスの全てを記録することがあり、コンプライアンス要件に違反する可能性がある。ロギングを有効にする前に、コンプライアンスチームに確認する。

SERVSEC 4：サーバーレスアプリケーション内の依存関係の脆弱性をどのように監視していますか？

  • アプリケーション依存関係の脆弱性スキャンに関しては、CI / CDパイプライン内に統合可能なOWASP Dependency Checkなどの商用ソリューションとOSSの両方が多数存在する。バージョン管理ソフトウェアリポジトリの一部として、AWS SDKを含むすべての依存関係を含めることが重要です。

SERVSEC 5：VPCアクセスの場合、AWS Lambda関数がアクセスできるネットワーク境界をどのように強制していますか？

  • Lambdaは、VPN接続を介してAWSの外部にあるリソースにアクセスするように設定できる。
  • セキュリティグループとNACLがネットワーク境界の基礎になる。コンプライアンス上の理由によりアウトバウンドトラフィックのフィルタリングが必要な場合、プロキシを配置することが考えられる。
  • コードレベルでのみネットワーク境界を実施することはお勧めしない。

SERVSEC 6：サーバレスアプリケーションで機密データをどのように保護していますか？

  • API Gatewayは、すべての通信でSSL/TLSを使用する。URLの一部であるリクエストパスとクエリ文字列は暗号化されないので注意が必要です。
  • 暗号化されたHTTPペイロードはAPI GatewayやLambdaから受信すると複合されるので、標準出力に出力された場合、機密データがCloudWatchログを介して誤って公開される可能性があるので注意。(ここ自信なし)
  • 不正な入力や傍受された入力は、システムへのアクセスを得るか、誤動作させる攻撃として使用することができる。
  • 機密データは、すべてのレイヤーで常に保護される必要がある。
  • API Gateway, Lambdaに関して、機密データはデータ操作前にクライアント側で暗号化されるか、HTTP POST要求の一部として送信される必要がある。ヘッダを暗号化することも含まれる。
    • これにより、CloudWatchログのデータが公開された場合のデータ漏洩が防止される。
  • 暗号化されたデータはDynamoDB、Amazon ES、またはAmazon S3のいずれかに永続させる。
  • 機密データが暗号化されていないAPI Gatewayでのログ記録を有効にすることもお勧めしない。API Gatewayのログを有効にする前に、コンプライアンスチームと相談してください。

SERVSEC 7：入力検証に関するあなたの戦略は何ですか？

AWS Well-Architected Lens – Serverless Applications まとめ 運用編

AWS

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編、セキュリティ編、信頼性編、パフォーマンス編、コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVOPS 1：サーバレスアプリケーションの異常をどのように監視し、対応していますか？

  • サーバーレス・アーキテクチャーの性質上、分散トレースを行うことは基本。
  • サーバーレスアプリケーションを変更すると、展開、変更、およびリリース管理が必要。
  • AWS X-Rayの分散トレース機能を使用することで、可視化されたサービスマップから迅速にトラブルシューティング行う。X-Rayは、パフォーマンスの低下を特定し、レイテンシ分布を含む異常を迅速に理解できる。
  • 個別レベルと集約レベルのアラームの設定が必要。
    • 個別レベルには以下のメトリクスが含まれる。
      • Lambda: Duration
      • API Gateway: IntegrationLatency
    • 集約レベルには以下のメトリクスが含まれる。
      • Lambda: Throttling, Errors
      • Step Functions: ActivitiesTimedOut, ActivitiesFailed, ActivitiesHeartbeatTimedOut
      • API Gateway: 5XXError, 4XXError
  • ビジネスとアプリケーションの洞察を捕捉するために、CloudWatchのカスタムメトリクスを使用する。

SERVOPS 2：変更の影響を最小限に抑えながら、サーバーレスアプリケーションをどのように進化させていますか？

  • API Gateway ステージ変数は、リリースするときに変更の数を最小限に抑えるのに役立つ。たとえば、ステージ変数は$ LATESTではなくLambdaのエイリアス名を参照できる。
  • AWS SAMを使用して、サーバレスアプリケーションをパッケージ化、デプロイ、モデリングする。また、SAM Localを使用すると、Lambda関数をローカルに開発する際のデバッグサイクルを高速化できる。
  • Lambda環境変数は、ソースコードと設定を分離するのに役立つ。たとえば、Lambda関数内で呼び出されたリソース名を変更する場合は、コードではなく環境変数のみを変更する。
  • 複数サーバーにまたがって共有している構成や鍵を制御する場合、環境変数に対してAmazon EC2システムマネージャ（SSM）のパラメータストア機能を検討する。パラメータストアで追加の遅延が発生する可能性があるため、SSMパラメータストアまたは環境変数の使用を決定する際にベンチマークを実行する必要がある。
  • 注: A/Bテストは、LambdaのTraffic Shifting機能で実現できる。変更時の停止時間をゼロにすることを推奨。
  • SAM Localは、パフォーマンスの目安としては使用しない。AWS環境では、計算リソースとネットワークレイテンシーが大きく異なるため、別途テストが必要。
  • API Gatewayステージ変数とLambdaエイリアス/バージョンは、ステージを分けるために使用してはいけない。これは、デプロイ単位のモニタリングの可視性を低下し、ツールの複雑さが増す。(ここ自信なし)
  • X-Rayは、AWS Lambdaの初期化や使用されているサービスの絞り込みなど、サービスメトリクスの詳細を提供している。CloudWatchのメトリクスだけでなく、X-Rayも使用する。これは、異常を特定して対応する際に役立つ。

EC2インスタンスの起動停止スケジューラー(CloudFormation)

AWS

起動時間、停止時間、タグを指定するだけで簡単に動きます。

下記リンクを参考にしました。
dev.classmethod.jp

CloudFormationを起動

https://console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/new?stackName=EC2StateScheduler&templateURL=https:%2F%2Fs3.amazonaws.com%2Fcm-public-cfn-templates-fujimoto%2Fec2-state-scheduler.yml

設定入力

平日9:00(JST)起動、平日22:00(JST)停止の例を記載します。
設定はUTCなので注意が必要です。

以下、設定です。

StartSchedule 0 0 ? * MON-FRI *
StopSchedule 0 13 ? * MON-FRI *
Ec2TagKey XXXX
Ec2TagValue YYYY

設定変更

起動時間、停止時間を変更したい場合はCloudWatch Eventsのルールからスケジュールを変更することが可能です。

タグはLambdaの環境変数から変更することが可能です。

JAWS DAYS 2018 参加レポート

参加レポート AWS

去年に引き続き今年も参加。

AWSのコミュニティが集まるイベントで、今年は1800人を超えたそうです。

海外コミュニティからの参加も多く、AWSのChiefエバンジェリストであるJeff Barrとツーショットで写真撮影してきました。

jawsdays2018.jaws-ug.jp

2018/03/21 追記
スライドまとまってました。見たセッションの資料ものせておきます。
JAWS DAYS 2018 スライドまとめ - Qiita

エッジデバイスでディープラーニング！ AWSを活用したエッジデバイスマネジメントの紹介 河崎 敏弥

speakerdeck.com

推論部分をなるべくIoTデバイス側で行えるかがカギになりそうです。
まだプレビューですが、Greengrass Inferenceに期待。

コニカミノルタのIoTの取り組み 中村 明彦


[ランチタイムセッション] アールスリーインスティテュート


「AWS Technical Evangelists Special talk session -スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来-」 Jeff Barr / Randall Hunt / Julio Faerman / Channy Yun / 亀田 治伸

aws.amazon.com




これからも手を動かしてアウトプットしていきます。

サービスをスケールさせるために〜AWSとAWS利用者の技術 荒木 靖宏

www.slideshare.net

最近のMediaServiceから始まり内容盛りだくさんでした。スライド公開希望。

編集業務の生産性向上へ向けたserverlessなアプローチ(EditTech) 落合 隆文

speakerdeck.com

既存のサービスの置き換えというよりは、新しい社内向けサービスをserverlessで構築したお話でした。少人数でやっているみたいですごい。

aiboの心はAWSの中にある？(RoboTech) 森本 良平

speakerdeck.com



デバイス認証の話はいつも気になるところ。各部署から情報を集めて実現というのが驚いた。各部署にAPIを叩いてもらって実現しているように見えました。こちらもスライド公開希望。

[DeepDive] AWS Japan SA Lightnings! 浅野佑貴 / 藤原吉規 / 福井厚 / 江川大地 / 塚越啓介 / 桐山隼人 / 畑史彦 / 大村幸敬

www.slideshare.net

www.slideshare.net

www.slideshare.net

AWS SAによる連続LTでした。CloudFormationの話は参考になりそうでした。スライド希望。→スライド貼りました

雑談

いろいろな人と話ました。メモしておきます。

  • Well Archtectedレビューは強制するのはダメ。
  • Cloud9で共同作業をするときにCodeCommitへのコミット履歴はどうなるか。
    • IAMユーザ単位でのアカウント払い出しになるのでコミット履歴もわけられる。
  • GuardDutyは全リージョンに設定するべきか。
    • 全部するのが好ましい。お金かからないし、逆に使ってないリージョンに対してオンにするのもありかもしれない。CloudWatchイベントとかSNSをリージョンごとに設定しないといけないのが少し不便。

AWS 役割別 IAM管理ポリシー

AWS

IAMポリシーを役割別に管理しようとすると、どんどん複雑になっていきます。
例えば、管理者と開発者は分けたいとか、本番環境のアクセスは絞りたいとか、いろいろあると思います。

個人的には用意されているものを組み合わせて使うのが良いと思っています。

ということで、よくリンクがわからなくなる「職務機能の AWS 管理ポリシー」をメモしておきます。
docs.aws.amazon.com

  • 管理者: AdministratorAccess
  • 請求: Billing
  • データベース管理者: DatabaseAdministrator
  • データサイエンティスト: DataScientist
  • 開発者パワーユーザー: PowerUserAccess
  • ネットワーク管理者: NetworkAdministrator
  • システム管理者: SystemAdministrator
  • セキュリティ監査人: SecurityAudit
  • サポートユーザー: SupportUser
  • 閲覧専用ユーザー: ViewOnlyAccess

開発時はIAMをいじれる人はAdministratorAccess、IAMをいじれない人はPowerUserAccess or SystemAdministratorにしておいて、本番運用が始まるときに他のポリシーにして権限を絞るイメージでしょうか。

あとは必要に応じてBillingをつけましょう。

監査要員はViewOnlyAccessで充分でしょう。ただしS3に個人情報などが入ってる場合は、S3側でアクセスをちゃんと絞りましょう。(例えばVPCエンドポイントで絞る)

無停止でEBSのボリュームを変更する方法(Linux)

AWS

Linuxで無停止でEBSのボリュームを変更する方法をメモしておきます。

公式を参考にしました。
Linux の EBS ボリュームのサイズ、IOPS、またはタイプの変更 - Amazon Elastic Compute Cloud

コンソールからEBSのボリュームを変更する

インスタンスにログインして事前確認。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  80G  0 disk
└─xvda1 202:1    0  80G  0 part /

コンソールからEBSのボリュームを選択して、「ボリュームタイプ」、「サイズ」を変更します。
f:id:yamano3201:20180308190609p:plain

80Gから400Gに変更されました。

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  400G  0 disk
└─xvda1 202:1    0   80G  0 part /

ボリュームのファイルシステムを拡張する

まずは事前確認。80G全てを使いつくしています。

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/xvda1      82436764 82336544         0 100% /
devtmpfs         1920364       60   1920304   1% /dev
tmpfs            1928944        0   1928944   0% /dev/shm

パーティションを拡張します。

$ sudo growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=167768030,end=167772126 new: size=838856670,end=838860766

つづいて各ファイルシステムのサイズを新しいボリューム容量に変更します。

$ sudo resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 5, new_desc_blocks = 25
The filesystem on /dev/xvda1 is now 104857083 (4k) blocks long.

事後確認して終了。

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/xvda1     412716188 82343232 330272708  20% /
devtmpfs         1920364       60   1920304   1% /dev
tmpfs            1928944        0   1928944   0% /dev/shm

AWS 逆引き(rDNS)設定を登録・解除する

AWS

AWSでは逆引き(rDNS)設定の登録・解除は申請ベースで行う必要があります。

rDNS登録

https://image.slidesharecdn.com/rdnsec2emailrequest20141022-141219200331-conversion-gate01/95/aws-ec2-e-rdns-4-638.jpg?cb=1503970710

rDNS解除

https://image.slidesharecdn.com/rdnsec2emailrequest20141022-141219200331-conversion-gate01/95/aws-ec2-e-rdns-6-638.jpg?cb=1503970710


また、rDNS設定したElastic IPを削除するためには、事前に逆引き設定の解除をする必要があります。

解除申請時、「Reverse DNS Record for EIP」には記載しないことに注意。登録申請時に記載します。