ヤサイブログ

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を設定できるので応用パターンは
もっと存在するのかなぁと思います。

以上です!

プログラミング言語の命名ルールとgolangにおける傾向について

プログラマー命名ルールに敏感です!敏感プログラマー
命名ルールに則ってない記述を見つけるともにゅっ(´・ω・`)とします。

それも、もちろん経緯があります。
同じプログラミング言語で記述されたファイルにおいて、
下記のような名前があったらどう思いますでしょうか。

CreateFutureIssue.java
delete_future_issue.java

・・・どちらかに揃えたいと思いますよね!まずはそこからになります。

命名には様々なルールがありますので、下記に紹介したあと、
golangにおける傾向を見ていきたいと思います。

キャメルケース(camelCase)

ラクダの背中のように見えることから Camel case と呼ばれます。

一番最初の単語を大文字にしたケースをアッパーキャメルケースまたは、
パスカルケースと呼ぶようです。

Javaにおいてインスタンス変数にキャメルケース、
クラスファイル名パスカルケースが使われているのかなという印象です!

Javaにおけるキャメルケースによるインスタンス変数の定義例

f:id:yasay:20190128203354p:plain

Javaにおけるパスカルケースによるクラスファイル名の定義例

f:id:yasay:20190128203602p:plain

スネークケース(snake_case)

地をはう蛇のように見えることから Snake case と呼ばれます。

Javaにおいてもfinal修飾子を加えたグローバルスコープ変数などに利用されます。
しかしながら、Javaのグローバルスコープ変数は大文字で記述する例が多く、
この場合はスクリーミングスネークケースとも呼ばれるようです。

Javaにおけるスネークケースによる変数の定義例

f:id:yasay:20190128204532p:plain

ケバブケース(kebab-case)

串が刺さったケバブのように見えることから Kebab case と呼びます。

GitHubリポジトリ名に使われる習慣がありますね。
文字の入力方法にしても「Shiftキー」を使う必要がないということで、
もっとも楽な入力方法ではあると思います。

マークダウンファイルのファイル名や、AWSリソースへの命名など、
個人的にはケバブケースの利用頻度が高まっています。
頭を大文字にしたケバブケースをトレインケースとも呼ぶようです。

マークダウンにおけるケバブケースによるファイル名の定義例

f:id:yasay:20190128204114p:plain

golangにおける命名ルールの傾向

golangの有名なOSSとして、「Docker」がありますね。
個人的に注目している「Vuls」も含めて、ソースコードを覗いてみました!
github.com
github.com
github.com
github.com

可視性

golangはメンバーの可視性(Public/Private)を
先頭大文字で判定する言語仕様がありますので、
変数やメソッド名の命名規則は基本的にキャメルケースまたは
パスカルケースで統一
されていますね。

golangにおけるキャメル・パスカルケースによる変数の定義例

f:id:yasay:20190128212626p:plain

ただし、golangのファイル名については
スネークケースとする習慣があるようです。

golangにおけるスネークケースによるファイル名の定義例

f:id:yasay:20190128212733p:plain

所感

プログラマー界隈では命名ルールは知ってて当たり前的なノリになるので、
新人に対して、変数やクラス名などの命名ルール規則まで詳しくフォローしてくれる人は
稀なのかなと思っています。

「ここ、キャメルケースになっているのでスネークケースに直して~」的なレビューが
飛んできた時、ベテランプログラマーなら問題ないでしょうが、
新人だと「スネークケースってなんだ?」ってなってしまうでしょうね。

各言語を利用する前に、命名ルールを把握しておけば
新規プロジェクトにスムーズに取り組めると思います!

参考サイト

tbpgr.hatenablog.com

以上です!

Alexa Skills Kit(ASK) SDK for Node.js バージョン2を適用した

ASK SDK for Node.js バージョン2を
私が個人で運用しているAlexaカスタムスキル「五月雨の音」に適用しました。

www.amazon.co.jp

実践した事柄を紹介します。

Alexa Skills Kit(ASK) SDK for Node.js バージョン2とは

まず、「ASK SDK for Node.js バージョン2」についてです。
Alexaカスタムスキルをコーディングする時に、
様々な言語を利用して直書きすることも可能ではあるのですが、
Alexaの機能にアクセスする命令をラップしたSDKも提供されています。
それが「ASK SDK for Node.js」になります。

github.com

ASK SDK for Node.jsは2018年5月にバージョン2がリリースされました。
私のカスタムスキルはバージョン1で動作していました。
今回、バージョン2を適用するようにマイグレーションしました。

実践したこと

1. テストコード記述によるハッピーパスの確認

ASK SDK for Node.js バージョン2にマイグレーションする時にまず実践したことが、
テストコードの記述です。

テストコードに関するセッションで有名なt.wadaさんに影響を受けて、
Alexaのテストコードによるハッピーパスの確認を行うようにしました。
Testing Frameworkは、Alexa Skill Test Frameworkを利用しました。

github.com

下記のようにテストを実行することで、動作確認が行えます。

f:id:yasay:20190126030725p:plain

2. CI環境の構築

テストコードを記述したことにより、CIをするための準備が整いました。
CI環境にはCircleCIを利用しました。

circleci.com

CircleCIはパブリックリポジトリであれば4コンテナまで無料で実行可能です。
Alexaカスタムスキル「五月雨の音」はパブリックリポジトリで運用しているため、
その恩恵を充分に受けることが出来ます。

ビルドおよびテストの結果はSlackのWebhookで通知されます。

f:id:yasay:20190126030903p:plain

CircleCIはローカルで動作確認するためのコマンドが用意されています。
ローカルなら、リポジトリへのpushをトリガーとする必要がないため、
円滑にCI環境の構築が行えます。

# ローカル実行のためのCLIをインストール
sudo curl https://raw.githubusercontent.com/CircleCI-Public/circleci-cli/master/install.sh \
--fail --show-error | bash

# アップデートの確認
circleci update check

# アップデートにインストール
circleci update install

# configファイル検証
circleci config validate

# localでの動作確認
circleci local execute

3. SAM CLIによるInvoke処理の確認

LambdaはAWS SAMによってデプロイしています。
SAM CLIはローカルでAWS Lambdaを実行するためのコンテナが起動します。
つまり、プロダクションにデプロイする前にLambdaのinvokeによる動作確認が出来ます。

# sam localによるLambdaのinvoke
sam local invoke "serverlessFunction" --event "./test/event/SoundsOfRainIntent.json"

4. ASK CLIによる動作確認

ASK CLIによるインテント呼び出し観点での動作確認をしました。
Alexaは自然言語処理を介してLambdaのIntentハンドラーが呼び出されるので、
Alexa側の呼び出しをシミュレートするコマンドが用意されています。
それが、「ASK CLI」になります。

# シミュレートの実行(LaunchRequest)
ask simulate --text "さみだれのおとを開いて" --locale ja-JP \
--skill-id ${ALEXA_SOUNDS_OF_RAIN_APP_ID} --profile xblood

5. オーディオファイルにCloudFrontを適用

このタイミングを機に、パブリックなS3バケットからのAudioファイルの取得から、
CloudFront経由に乗り換えました。許可したくないアクセス元が存在する場合、
WAFによるセキュリティ対策も可能になりました。
AWSリソースはTerraformを用いて構築しました。

6. エイリアス定義の見直し

LambdaのエイリアスにAutoPublishAlias属性を使用していたのですが、
Lambda単体でAutoPublishAlias属性を利用するメリットが今回のケースでは無いため、
アライアスはマネージメントコンソールから付与するように変更しました。

課題点

ASK SDK for Node.js バージョン2の適用は成功しましたが、課題も残りました。

コード補完が使えない。

Intentに対応する各種ハンドラーはconstで定義された関数として記述します。
この時、私のvscodeの開発環境ではコード補完が行われなかったため、
テストコードを実行するまでは記述内容が正しいのか不安になることがありました。

これについては私のNode.jsスキルが上昇すれば解決すると思いますが、
TypeScriptによるカスタムスキルの実装も実践していきたい。

// handlerInputにコード補完が利用できない
const LaunchRequestHandler = {
    canHandle(handlerInput) {
        return handlerInput.requestEnvelope.request.type === 'LaunchRequest';
    },
    handle(handlerInput) {
        console.log('Start LaunchRequest');
        return handlerInput.responseBuilder
            .speak(HELP_MESSAGE)
            .reprompt(HELP_MESSAGE)
            .getResponse();
    }
};

CD環境の構築

CI環境まで構築できれば、あと少しの手間でCD環境も構築できます。
今後はリリースブランチへのプッシュによるCD環境構築を実践していきたい。

おわりに

常に自分にとって新しい関心事をインプットとし、
アウトプットも今までにないことをする。
この姿勢を維持し、これからも取り組んでいきたいと思います。