ヤサイブログ

I'll keep hacking on fun. ~ 学びよ、加速しろ ~

サーバーレスで活用するCloudFormationのNested Applications

「サーバーレスで活用するCloudFormationのNested Applications」というタイトルで 下記のサイトにブログを投稿させて頂きました。✍

blog.mmmcorp.co.jp

よろしければ、ご欄になってください! 🙋‍♂️

AppSyncのパイプラインリソルバーを利用して履歴データを管理する

最近はプライベートではAppSync、
業務ではgolangをキャッチアップしています。

「AppSyncのパイプラインリソルバーを利用して履歴データを管理する」というタイトルで
下記のサイトにブログを投稿させて頂きました。

blog.mmmcorp.co.jp

よろしければ、ご参照下さい! 以上です!

JAWS DAYS 2019 行ってきました!

f:id:yasay:20190228233944j:plain:w350

行ってきました❗️JAWS DAYS 2019❗️
所用があり午後からの参加で、1セッションのみでしたが、
相変わらずのお祭り的なムードを楽しんできました❗️😃

レポートしていきます!📝

レポート

15:10 ~ 16:00 PenTester が知っている危ないAWS 環境の共通点 ~攻撃者視点よりお届けする狙われやすいAWSの穴~

www.slideshare.net

  • プラットフォームとしてのセキュリティは堅牢
  • 堅牢でも使い方次第でセキュリティインシデントは発生する。
  • Credentialを悪用する状況が最も危険と考える。
  • よくある事例
    • スピアフィッシングでメールアドレス・パスワードを取得している。
    • Github上にAWSのアクセスキー公開の危険
      • AWSもスキャンしてくれるけど、攻撃者の方がアクセスキーを探すほうが速い
      • Privateリポジトリであっても別口から盗まれる可能性。
      • SSRFを利用したCredentialの
      • サーバー内に配置されているCredentialの取得
  • 場合によってはこれで終わりではない

    • 権限昇格によってRootを取られる可能性がある。
      • Lambdaにロールを付与することによる、高い権限を取得する例
  • 攻撃デモ

    • Pacuというツールを利用
      • アクセスキーからユーザー情報取ってこれる。
      • ポリシー割り当ても確認できる。
      • アクセスキーを取得できたら、指定したユーザーに新しいアクセスキーを作成し、バックドアを作る。
      • システムスマネージャーを起動して、EC2に侵入する。
  • 対策

    • Credentialの漏洩を防止・悪用を抑制・悪用を検知
    • IAMのベストプラクティスに従う
    • 特にアクセスキーの扱いに注意
    • AWS Trusted Advisor
    • ツールも万能の神様ではなので、出来ることと、出来ないことの確認が大事
    • git-secretsを使う
    • アクセス許可の境界(Permissions Boundary)
      • Permission PolicyとPermission Boundaryの2つのポリシーで制御
    • aws:RequestedRegionでリージョンを制限して被害範囲を限定し、検知も容易にする。
    • AWS CloudTrail、CloudWatchによる悪用の検知
    • Amazon Guard Duty

所感

Pacuによる攻撃デモは見ているだけで恐ろしいものがありました。
SSRFによる攻撃に備えて、MFAを抜かりなく設定したいと思います。

短い時間でしたが、
今年もイベントブースにセッションと有意義な時間を過ごさせて頂きました❗️

参考サイト

JAWS DAYS 2019 資料まとめ - Qiita

以上です!

AppSyncのデータソースとしてgolangのLambdaを利用する

「AppSyncのデータソースとしてgolangのLambdaを利用する」というタイトルで
下記のサイトにブログを投稿させて頂きました。✍

blog.mmmcorp.co.jp

よろしければ、ご欄になってください! 🙋‍♂️

AWS セキュリティグループの適用パターン

AWSのセキュリティグループにおいて、
私が直近で利用している適用パターンを紹介します。
(ちなみに、名称は私が勝手に考えました(´・ω・`))

allow self subnet方式

セキュリティグループ(以下SG)のインバウンドルールに、
SGを設定することができることを利用し、
簡易的にインスタンス間のインバウンドを有効にする方法です。

f:id:yasay:20190128223923p:plain

メリットとして、当該SGを設定したインスタンス全てにおいて、
特定ポートの疎通が可能になるので、インスタンス個別に新しい SGを定義する
必要がなくなります。

allow ELB's sg方式

上記のallow self subnet方式に近いです。
こちらの場合、ELBのリスナとして設定されているEC2インスタンスのSGに
ELBのSGを設定することで、ELB経由のみしかアクセスさせないことを
簡単に実現できます。

f:id:yasay:20190128225305p:plain

analog sg方式

こちらは番外的な位置付けではあります。
対抗サーバのグローバルIPアドレスを登録したSGを一つ作り、
インスタンスに適用します。

同じサブネットに配置しているサーバ間連携にも関わらず
パブリックIPで一度外に出てしまっているようなサーバにおいて、
特定のIPのみ許可するSGを適用することで、許可したアクセス元以外を遮断します。

f:id:yasay:20190128230830p:plain

何を言っているんだと思われるかもしれませんが、
パブリックサブネットをNATゲートウェイを利用せずに、
擬似的にプライベートサブネットにする方法だと思っていただければと。
( ※それでも何を言っているのか・・(ry )

プライベートIP間で通信すればいいじゃん的な話ではあるんですが、
パブリックIPがアプリケーション内にハードコーディングされているような
レガシー(;ω;)なサーバアプリケーションにおいて効果を発揮します。

おわりに

他にもよい適用パターンがあれば、
本エントリーを更新していきたいと思っていますが、
インバウンドルールにSGを設定できるので応用パターンは
もっと存在するのかなぁと思います。

以上です!