しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決！」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最

コンバンハ、千葉（幸）です。 突然ですが問題です。 以下の条件があったとします。 同一の AWS アカウントに S3 バケット A と IAM ユーザー A が存在する IAM ユーザー A の Permissions boundary には AWS 管理ポリシーViewOnlyAccessが設定されている ここで、IAM ユーザー A が S3 バケット A に対してPutObjectを実行したいとします。（補足しておくと、ViewOnlyAccessにはPutObjectの Allow は含まれていません。） 以下のうち、アクションの結果について最も適切に説明しているものを選択してください。 IAM ユーザー A の Permissions policy で適切な Allow が設定されていればアクションは成功する S3 バケット A のバケットポリシーで適切な Allow が設定され

コンバンハ、千葉（幸）です。 2019年12月に新発表となったVPC Ingress Routingですが、初見でなかなか理解に苦労しました。 https://aws.amazon.com/jp/about-aws/whats-new/2019/12/amazon-vpc-ingress-routing-insert-virtual-appliances-forwarding-path-vpc-traffic/ ルートテーブルをインターネットゲートウェイおよび仮想プライベートゲートウェイと関連付けることができるようになりました。また、Amazon Virtual Private Cloud (Amazon VPC) の受信および送信トラフィックを VPC の仮想アプライアンスを通してリダイレクトできるようになりました。 発表時にはすでに弊社千葉（淳）が設定方法などをブログにしているのですが

コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程のアップデートで CloudFront の IP アドレスが Managed Prefix List でサポートされました。これにより CloudFront を経由しない不正なアクセスを簡単に弾くことが可能になります。CMS など CloudFront を使う機会が多いサービスではぜひご利用ください。また CloudFront で AWS WAF を使ってセキュリティを向上している場合の迂回路を塞ぐことができます。 Amazon CloudFront now supports a managed prefix list CloudFront を経由しないアクセス 今まで AWS で CloudFront を経由したアクセスだけ強制させる場合は、CloudFront ではカスタムヘッダを付与して、その値を ALB や Web サーバで

Gitのサブモジュール内で何か変更などがあると親リポジトリ側でコミットができません。解決方法は主に2個あるようです。実際に再現させつつ、その解決方法を紹介します。 こんにちは。サービスグループの武田です。 バージョン管理システムであるGitはソースコードなどをリポジトリという単位で管理します。さらにGitにはサブモジュールという機能があり、これを利用することで別のリポジトリを自身のリポジトリ内で再利用できます。 とても便利なサブモジュール機能なのですが、サブモジュール内で何か変更などがあると親リポジトリ側でコミットができません。たとえばサブモジュール内でビルドなどをして成果物が生成され、それが.gitignoreに書かれていない場合などが該当します。とはいえ、サブモジュールでそれをコミットするわけにもいきません。 解決方法は主に2個あるようです。実際に再現させつつ、その解決方法を紹介します

CX事業本部＠大阪の岩田です。2021/3/18付けのアップデートでS3に対するGetリクエストのレスポンスをLambdaで加工するS3 Object Lambdaという機能が利用できるようになりました。 S3 Object Lambdaとは？ S3に対するGETリクエストをトリガーにLambdaを起動し、レスポンスを自由に加工できる機能です。例えば以下のようなユースケースが想定されています。 行のフィルタリング 画像の動的なリサイズ 機密データのマスク この機能を利用するには、S3アクセスポイントをラップした「オブジェクト Lambda アクセスポイント」が必要になります。クライアントが「オブジェクト Lambda アクセスポイント」経由でオブジェクトのGETを試行するとLambdaが起動し、Lambdaによってカスタマイズされたレスポンスが返却されるという流れになります。 S3アクセス

AWSのマネージドルールを利用して Log4jの脆弱性(CVE-2021-44228)を緩和するAWS WAFを、CloudFormatinで作成してみました。 AWSチームのすずきです。 Log4jの脆弱性を緩和するため、AWSのマネージドルールに含まれる「Log4JRCE」のみ利用するAWS WAF、 CloudFormatinで設置する機会がありましたので紹介させて頂きます。 WAF設定 WebACL ELB(ALB)の保護で利用するため、「Scope: REGIONAL」としました。 AWSのマネージドルール「AWSManagedRulesKnownBadInputsRuleSet」の最新バージョンを利用する指定を行いました。 誤検知による副作用を最小化するため、「Log4JRCE」以外のルールに該当したリクエストは受け入れる除外設定を行いました。 WebACL: Type: AW

AWSチームのすずきです。 2021年12月11日、 AWS の Managed Ruleとして提供されている AWSManagedRulesKnownBadInputsRuleSetに新しい保護ルール「Log4JRCE」が追加されました。 Apache Log4j2 Issue (CVE-2021-44228) Log4j の脆弱性(CVE-2021-44228)対策として、AWS WAFの有効性を確かめる機会がありましたので、紹介させていただきます。 AWS Managed Rule Known bad inputs 新しいルール 「Log4JRCE」 が追加されました。 試してみた WAF(ACLs)設定 AWSManagedRulesKnownBadInputsRuleSet のみ設定した WebACLを用意しました。 BadInputsRuleSetのバージョンはデフォルト、検証

インフラをコードで管理するInfrastructure as Codeだからこそ、必要なドキュメントについての考察とそれの管理方法についてLTした様子です。 「なんや、この視聴者数…　震えが来るぜ・・・」 先日開催されたInfra Study Meetup #2「VM時代の開発とCloud Native時代の開発」 - connpassにおいて、「IaCにおける理想のドキュメント管理を目指す」という内容でLTしてきましたので、その内容をお届けします。 当日は、イベント内容も登壇者も超絶豪華で、なんとリアルタイム視聴者数1000人超えということで、さすがに自分も緊張しました。まじで。 青山さんのメインテーマがKubernetesの話であり、前後それに関わるテーマが中心の中、Kubernetesもコンテナも1ミリもでてこない発表にしたのですが、IaCに関わる普遍的な考慮ポイントについて喋れたの

GitHub Actionsで複数Workflowを追加していくと、Workflow間でStepが重複している事はよくあります。重複部分を共有化できる機能としてcomposite run stepsも既にリリースされていますが、正直色々ちょっとわかりにくい。原因としては以下あたり。 今使っているリポジトリで有効か分からない 使えるとしてどう使えばいいのかわからない 最初にこの機能を知ったときには「共有化したStepをパブリックにすること前提」という一文を見かけて「あ、オープンソースじゃないと使えないな」と判断したのですが、最近幾つか検索して見当たった事例をみると同一リポジトリ内に設置できることを知り、実際にやってみました。 Composite Run Stepを使える条件 GitHub Actionsが使えるなら使えます。Actionsが使える条件は新プランであること(プライベートリポジト

EKS初心者の方向けに、EKS周辺のAWSリソースがどのように関連して動作しているのかをステップバイステップでEKSCTLが担っている役割を中心に説明しました。 先日、「EKS祭り」をテーマにJAWS-UGコンテナ支部 #16を開催しました。 JAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイ - connpass EKS縛りというだいぶ濃いイベントの中で、自分はトップバッターで「今こそ振り返るEKSの基礎」と第して喋ってきたのでその内容をまとめます。基礎といえども普段隠れがちなEKSに関連するAWSリソースについてフォーカスを当てたある意味マニアックな内容だと思うので、EKS気になる方は是非ご覧ください。 （祭） ∧ ∧ Y　 ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉     EKS ﾀﾉｼｲﾖ ｺﾚﾏｼﾞﾃﾞ |_|＿| し'´Ｊ この記事の

コンニチハ、千葉です。 監査ログを悪意ある削除から、何が何でも守っていくぞのコーナーです。 みなさんは、AWSの監査ログ(CloudTrail)をどのように保護していますか？ CloudTrail を保護するために CloudTrail ログファイルの整合性の検証を有効化 CloudTrail ログファイルを暗号化 S3上のファイルを削除から守るために MFA削除の設定 が考えられます。 よし、保護している！って思っても、ユーザーが Admin 権限を持っている場合、暗号化していようが整合性チェックしていようがデータは削除可能です。しかも、 CloudTrail のレコーディング自体を停止 もできちゃいます。つまり、監査ログが保存されなくなり、何が行われたのか調査が難しくなります。 もしも、万が一、強い 権限がある Admin が第３者に渡ったとしても、大切なログを守りたいです。Admin

S3 へのアクセス元を限定する場合に、複数の否定条件を使った Deny でバケットポリシーを書くことがありますが、これは AND 条件なの？ OR 条件なの？ と混乱することがあるので、わかりやすく図解で考えてみました。 想定環境 今回、想定する環境は下図のとおりです。前提条件として「同一アカウントの IAM ポリシーで、S3へのアクセス権限は与えられている」(明示的な Allow は不要)とします。 "192.228.xx.xx/32" はインターネット経由のアクセス "10.0.0.0/24" は、VPC エンドポイント経由のアクセス バケットポリシーのおさらい バケットポリシーについては、弊社 北野の記事がとても参考になります。 S3バケットポリシーの具体例で学ぶAWSのPolicyドキュメント 押さえておきたいのは以下の図です。 つまり複数条件を書く場合、以下のいずれかになります。