AWS Startup ブログ
【週刊 Ask An Expert #15】 サーバーレスアプリケーションでのセキュリティ対策って?先週の #AWSLoft で受けた質問10選
こんにちは、スタートアップ ソリューションアーキテクトの塚田 (Twitter: @akitsukada) です。好きな AWS サービスは AWS Amplify を通じて使える各種サービス、特に Amazon Pinpoint です。8/8(木) 19:00、Amplify & Chalice のハンズオンワークショップを開催するので、アプリケーションデベロッパーの方や、楽してさくっとサービスを構築したい方はぜひ Loft にお越しください。参加登録は↓こちらから。
さて、今回の週刊 Ask An Expert 第15回目をお届けします。「参考になったわ!」「ええ内容や!」と思っていただけたら、ぜひハッシュタグ #AWSLoft を付けてシェアしてください。もちろん、改善点・ご要望もお待ちしております。
Ask An Expert ?
皆さん AWS Loft Tokyo はご存知でしょうか?
目黒セントラルスクエア17Fにある、AWS を利用中のスタートアップとデベロッパーのためのコワーキングおよびイベントスペースです。その一角に AWS のエキスパート – Solutions Architect (SA) や Cloud Support Engineer (CSE) – といった中の人に技術的な質問ができる、Ask An Expert カウンターがあります。そこでは毎月、来場者の方から100件以上にものぼるご相談をお受けしています。
この連載「週刊 Ask An Expert」では、そんな多数のご相談を非常にざっくりとまとめて掲載してきましたが、今回からは新しい試みとして我々 Startup SAs が 独断で面白かった質問を 10 個選び、やはりざっくりとまとめてご紹介していきます。他の AWS Loft 利用者がどんな質問をしているのか、自分が知らなかった新しいトピックはないか、Ask An Expert ってどんなところなのか、一緒に見ていきましょう!
週刊 Ask An Expert #15 (2019/07/22 – 07/26)
この週の対応者は SA: 浅野・荒木・岩野・塚田と CSE: 榎本・古野でした。
Q1: Amazon Cognito User Pools でユーザーのサインアップ・サインイン機能を実装している。サインイン済ユーザーの属性情報を取得するために、クライアントからのリクエストごとにサーバーサイドで GetUser API を叩きたいが、API 制限の上限緩和は可能か。
緩和の可否は実際の目的や設計などによって異なりますが、今回の場合ユーザーの属性情報を取得したいとのことなので、 GetUser を都度叩くのではなく ID トークンを復号して得られるクレームからユーザー情報を取得する方法が適切と思われます。
参考:Amazon Cognito JSON ウェブトークンの署名を復号して検証する方法を教えてください。
この方法であれば API アクセスすることなくサインイン中のユーザー情報を取得することができるので、まずこちらをご検討ください。
※ なお、 各種上限緩和の申請自体は Ask An Expert でなくカスタマーサポートで承ります。詳細はこちらのドキュメントをご覧ください。
Q2: スマートフォンアプリを設計中。スマホアプリから直接 Amazon DynamoDB を操作する事もできると思うが、スマホアプリ -> Amazon API Gateway -> AWS Lambda -> DynamoDB など API を経由する方法とどちらがよいか。
サービス・アプリの要件次第なのでケースバイケースですが、両者には例えば以下のような違いが挙げられます。
スマートフォンアプリケーションから 直接 DynamoDB (2-Tierアーキテクチャ) |
API Gateway, Lambda を 経由して DynamoDB |
|
---|---|---|
バックエンドアクセスの認可 | Cognito ID Pool から一時的な認証情報を取得し、DynamoDB にアクセスする権限を得る。 また、ポリシー変数( ${cognito-identity.amazonaws.com:sub} など)を利用することで、自分の IdentityID に一致する値のアイテムにのみアクセスを許可するなどのファイングレインアクセスコントロールが可能。 |
Cognito Authorizer、IAM Authorizer、Lambda Authorizer、なし(Publicアクセスを許可) のうち任意の方法を選択できる。また、Lambda Authorizer またはバックエンドの Lambda ファンクション内で動的に(例えば DynamoDB 等から情報を取得するなどして)アクセス可否を判定可能。 |
アプリケーションロジックの実装場所 | サーバーサイドアプリケーションが介在しないため、関連するコードは全てスマートフォンアプリに書く。 | スマートフォンアプリまたはバックエンドの Lambda ファンクションに書く。 |
Web API としての諸々の制御、機能 (API キーの利用、アクセスロギング、 スロットリング等の制御、キャッシュ、 AWS WAF との併用など) |
DynamoDB Accelerator(DAX) によるキャッシュ、キャパシティユニット超過によるスロットリングはある。 | API キー、アクセスログの出力、キャッシュ、使用量プランによる API キーごとのキャッシュ・スロットリング制御、AWS WAF との統合が設定できる。 |
アプリケーションおよびサービスのニーズに合った方法をお選びください。
Q3: AWS Control Tower とは一体?
組織内で複数の AWS アカウントを作成し管理する必要があるとき、各アカウントに適用するセキュリティポリシーを統合管理でき、既存アカウントのポリシー準拠状況を管理したり、ポリシーに則った新規アカウントを素早く作成できたりするサービスです。ガードレールという概念で、アカウント内での操作を許可・禁止したり、AWS Config Rules を利用して違反を検知したりすることができます。複数アカウントを統制する際にぜひお使いください。
Q4: ALB – Nginx – App Server の構成をとっている。全体を AWS CloudFormation で管理しているのだが、 Nginx の conf に書いてあるリダイレクトやルーティング設定はどう運用すればよいか。
.conf ファイルの内容まで含めて CloudFormation テンプレートに記述することも可能ですが、現在 Nginx で設定している内容をお伺いしたところ ALB のパスベースのルーティングやリダイレクトで実現可能なものだったため、Nginx を無くして ALB の設定に寄せる構成を提案しました。
Q5: 今、一つの AWS アカウントで複数サービスを運用中だが、これをサービスごとのアカウントに分けていきたい。その場合、AWS Route 53 は複数サービスに関わるのだが、どのアカウントに置けばよいのか。
複数アカウントにまたがって影響のあるものは共有リソースとして、そのためのアカウントを各サービス用のアカウントとは別に用意するデザインパターンがあります。その他、支払い用アカウント、ID 管理用アカウント、セキュリティ・ログ統括用アカウント等、サービスとは別の単位で専用のアカウントを管理するアカウント構成が考えられます。
Q6: 品番と図面のデータベースを用意したい。Lambda から使うのであれば、やはり DynamoDB が推奨されるのか?
Lambda と RDS を併用することがアンチパターンとして挙げられることがありますが、その理由は「OLTP のシステムに採用した場合、多数の Lambda Function が同時に実行された場合のコネクションが溢れる」「VPC 内のリソース(=RDS)にアクセスする場合、Lambda に VPC を設定する必要があり、関数起動時にコールドスタートの時間が追加でかかり得る」ことを指しています。逆に言えば、ユースケースを考慮の上それらのリスクコントロールができる、またはそれらの現象が許容出来る場合は、問題なくお使いいただけます。それとは別の観点で、DynamoDB は NoSQL、RDS は RDBMS であり、それぞれ機能の差異や向き不向きがあるので、機能要件や学習コストを考慮したうえで適切なものをお選びください。
【旧版・説明欄参照ください】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス
Q7: Amazon CloudWatch Alarms -> Amazon SNS -> Lambda の流れで通知を行いたい。
7-1) Alarm のステータスが Alarm になっても SNS からLambda が呼ばれない。なぜか。
Lambda が SNS からの呼び出しを許可していませんでした。AddPermission で SNS から Lambda Function の呼び出しを許可し、解決しました。
7-2) 他の AWS アカウントのメトリクスに対してアラームを作成できるか。
できません。
7-3) 複数メトリクスのデータを集計した値に対するアラームは作成できるか。例えば、2xx/4xx/5xx のレスポンスコード毎にメトリクスが作成されていたとして、これらの合計値に対して閾値を設定したい。
メトリクスの数式に基づくアラームで実現可能です。演算子や関数を用いた数式を定義できます。
7-4) SNS から Lambda の呼び出しに失敗していることを確認する手段はあるか。
NumberOfNotificationsFailed メトリクスをご利用いただけます。
Q8: Amazon Redshift のチューニングについて相談したい。現在単一の Redshift クラスターを、Tableau などの BI ツールからの参照、バッチ・分析処理、メール配信のステータス管理など複数の用途で使用している。BI ツールの利用やバッチ処理にリソースが取られており、メール配信処理、メール配信のステータス変更処理が遅延する問題が発生している。Workload Management(WLM) によるワークロード管理は行っていない。
詳しくお伺いしたところ、遅延の原因が「キューが詰まっていて目的の処理が開始されない」のか「目的の処理の実行時間が想定より長い」のか不明な状態でした。いったん Redshift のクエリチューニングガイダンスをご紹介し、内容を読んで頂くようお願いしました。
また、より詳しくお話を聞きたいとのことでしたので、AWS 個別相談会をご案内しました。
Q9: B2B のサーバーレスアプリケーション(Amplify で API Gateway、Lambda、Cognito 利用) を構築中。セキュリティ対策について相談したい。AWS WAF を使うことを考えている。
WAF, API Gateway, Lambda それぞれのレイヤーで対策することを検討いただきたいです。例えば、WAF を活用することでクローラーや Bot からのアクセスをブロックすることが可能になり、API Gateway で認証を有効化することで匿名ユーザーからのアクセスを遮断することができます。最終的にパラメーターが正常なものであるかの確認は、Lambda のレイヤーで判断するものになります。
Serverless Application Security on AWS
Q10: コスト管理や API 操作等のために、各 AWS リソースにタグが付いている状態を強制、維持したい。違反したリソースは削除するなどの措置を取りたい。
AWS Config Rules の required-tags ルールを活用することでタグが付与されていないリソースの検出、通知が可能です。また、違反したリソースに対しては修復アクションの機能によって任意の AWS Systems Manager Automation を実行可能です。例えば、違反した EC2 インスタンスの停止や削除を実現できます。
週刊 Ask An Expert まとめ、今回はここまで
最後までお読み頂きありがとうございます。
冒頭に書いたように、執筆者の独断により興味深かった質問 10 個を選び、且つざっくりとまとめて記載しているため、実際にはより具体的な質問をより多く頂いていますが、様々なご相談があることが伝わっていれば嬉しいです。まだ Ask An Expert カウンターをご利用になったことがない方も、AWS Loft Tokyo をご利用の際はぜひお気軽にご質問くださいね。
※Ask An Expert が混雑してお待ちいただく場合、またはエキスパートが不在の場合がございます。何卒ご容赦ください。
それではまた次回をお楽しみに!
このブログの著者
塚田 朗弘(Akihiro Tsukada)
スタートアップソリューションアーキテクト。好きなサービスは AWS Amplify、AWS AppSync、Amazon Pinpoint。趣味は頭を触ってくる子供と遊ぶこと。