IDEA Note

  • kms:ViaService の考え方について

    kms:ViaService を利用して、CMK を呼び出していない時」というポリシーの書き方をすることができる

                    "Null": {
                        "kms:ViaService": "true"
                    },
    

    この部分は Classmethod さんのブログが非常にわかりやすい

    https://dev.classmethod.jp/articles/ebs-kms-sourceip/

    kms:ViaServiceは、CMKの使用を指定のAWSサービスからのリクエストに制限する条件キーであり、

    Nullは、条件キーの存在を確認する条件演算子を指す。

    Nullで {"kms:ViaService": "true"}と指定すると、「kms:ViaServiceが存在しない(≒CMKを呼び出していない)」という条件になる。

    これを接続元IPアドレスを制限する条件に追加することで、「CMKを呼び出していない かつ 接続元IPを制限する」という条件になる。

  • NoCode ツール upflowyを試してみた

    NoCode ツール upflowyを試してみた

    直感的に Webページを作る NoCodeツールです。

    https://www.upflowy.com/

    Product Huntで、2021年9月9日週のランキングで1位を獲得しています。

    日本語で詳しい説明はtakuya hayashiさんがされているので、詳細はそちらをご覧ください。

    https://note.com/woods0918/n/n7d6364519146

    さまざまな NoCode ツールは発表されていますが、upflowy はどのような特徴をもっているのか実際に触って調べてみましたので完結にまとめました。

    ユーザー登録

    https://app.upflowy.com/

    これ自体は他のWebサービス同様、ポチポチと済ませます。

    使い方

    navi が教えてくれます。現在は日本語対応していません。

    いくつかのテンプレートは用意されていて、自由に選ぶことができます。

    使ってみた

    無料アカウントではDB 接続ができません。

    そのため、ログイン画面で入力されたID/PW を IF 文でただの文字列として判断し、照合できたらログイン後のページを出すためだけの画面をつくりました。もちろん、ログイントークンとかもなにもないただの判定するだけのページです。

    サンプルで作ったフローは以下の通りです。

    判定ロジックはこんな感じにしました。ただの判定です。

    できたページが以下の通り

    サンプルページを公開します。ご自由にいじってみてください。

    https://my.upflowy.com/sqr-tsukada-test

    ID/PW は以下の通り

    test@sumito.jp
    password
    

    所感

    現在は最低限の機能のみに絞られていて、上記ページの作成だけであれば学習時間込みでも 30分で作れました。

    実際の運用を考える

    アウトバウンドIP 固定化できない

    これについてはどこにも記載がないので、直接聞いてみた。

    どうやら現時点では upflowy からのアウトバウンドIP を限定することができず、API 側で IP 制限がかかっている場合ひっかかってしまいそうです。

    ログインページを作ることできる?

    パスワード入力画面は、パスワードがそのまま画面に表示されるのではなく、せめてアスタリスクなどでマスキングされた状態で画面に表示して欲しい。

    いじってみたところそれができなそうだったので、直接聞いてみました。

    こちらは現在開発中の機能で、現在使えないようです。

    使ってみて思ったこと

    アンケート画面を作ったり、Mock を作ったりという利用では十分使えるのではないかと思いました。

    しかし、Webページを作るにはまだまだ機能が不十分という印象を感じです。

    アップデートの予定はある様なので、今後に期待したいと思います。

  • AWS Inspector と AWS Trusted Advisor について

    あまり日常的に触らないサービスの1つである。

    何度もこの違いについて過去に調べてはいたが、使わないものは忘れてしまう。

    メモがてら残す。

    AWS Inspector とは

    https://aws.amazon.com/jp/inspector/

    EC2 インスタンス上の脆弱性をチェック ができると考えて良さそうだ。

    また、脆弱性チェック対象のインスタンスは、エージェントをインストールする必要がある。

    AWS Trusted Advisor とは

    https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/

    こちらはエージェントのインストール不要。

    インスタンスをスキャンし、AWS のベストプラクティスを元に、
    • コストの最適化
    • セキュリティ
    • 耐障害性
    • パフォーマンス
    • サービスの制限

    の5つの項目について、チェックすることが出来るツール。

    まとめ

    それぞれ1行でまとめると

    AWS Inspector は脆弱性検知することが必要でエージェントが必須

    AWS Trusted Advisor は AWS のベストプラクティスに沿って作られているかスキャン、レポーティングしてくれる機能

    と考えておけば良さそうだ

  • S3バケットアクションはどのリソースにも適用されません

    {
      "Id": "xxxxx",
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "xxxxx",
          "Action": [
            "s3:GetObject"
          ],
          "Effect": "Allow",
          "Resource": "arn:aws:s3:::hoge-hoge",
          "Principal": "*"
        }
      ]
    }
    

    この設定をしていて アクションはステートメント内のどのリソースにも適用されません とエラーが出る

    原因は、バケットのみ Resource として指定しているためであり、この問題を解消するには

          "Resource": "arn:aws:s3:::hoge-hoge/*",
    

    のようにバケット内のどのオブジェクトにアクセスを許可するかを必ず指定する必要がある。

  • CMK キーの自動キーローテーション間隔について

    AWS 管理のCMK は我々ユーザーで管理することはできないが、 3年ごとに自動でローテーションされる

    AWS 管理の CMK AWS 管理の CMK のキーローテーションを管理することはできません。AWS KMS は AWS 管理の CMK を 3 年ごと (1095 日) に自動的にローテーションします。

    https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html

    なお、我々ユーザーが管理する CMK は 365 日に設定されている

    キーの自動ローテーションを有効にすると、AWS KMS は有効にした日から CMK を 365 日ローテーションし、その後は 365 日ごとにローテーションします。

    https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html

  • 利用しているAWS リソースを確認する

    監査などを目的とし、どのリソースをどれだけ使われているか確認したいことがあるが、

    それを確認するには AWS config が便利なので紹介。

    とはいえ AWS config からリソースを選択するだけ。

    使っていないと思っていたものが、実は使っていたといったケースもこれで確認できる。
  • S3 の CORS について

    s3 は通常、静的ウエブサイトをホストすることができるが、JavaScript 経由で バケットに対する GET/POST を行う際は注意が必要である。

    よくある事例

    S3 に hoge.com という名前でホストしたとする。

    このバケットに保存されている JavaScript によって、S3 のエンドポイントである hoge.s3.ap-northeast-1.amazonaws.com に GET/POST を行おうとすると、

    ブラウザは通常、別ドメインに対する接続しようとする JavaScript をブロックする。

    CORS を使用すると、hoge.com からのクロスオリジンリクエストを許可できるようにバケットを設定することができる。

    参考情報

    https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html

  • AWS コンソールログイン時の他要素認証

    カスタムIAM ポリシーを設定することで、MFA を有効化することができる。

        "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    

    ポイントは、

    Conditiol 文を使用すると、ユーザーが MFA 認証されている場合にのみリソースを操作できるようになる。

    aws:MultiFactorAuthPresent 句を true としてマークする必要がある。

    参考情報

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html

  • fatal: unable to access ‘https://gopkg.in/yaml.v2/’: server certificate verification failed. CAfile: none CRLfile: none

    ある時、

    go get -v github.com/rubenv/sql-migrate/...
    

    を実施したら出るようになった。

    go get -v github.com/rubenv/sql-migrate/...
    github.com/rubenv/sql-migrate (download)
    get "gopkg.in/gorp.v1": found meta tag get.metaImport{Prefix:"gopkg.in/gorp.v1", VCS:"git", RepoRoot:"https://gopkg.in/gorp.v1"} at //gopkg.in/gorp.v1?go-get=1
    
    (中略)
    
    get "gopkg.in/yaml.v2": found meta tag get.metaImport{Prefix:"gopkg.in/yaml.v2", VCS:"git", RepoRoot:"https://gopkg.in/yaml.v2"} at //gopkg.in/yaml.v2?go-get=1
    gopkg.in/yaml.v2 (download)
    # cd .; git clone -- https://gopkg.in/yaml.v2 /go/src/gopkg.in/yaml.v2
    Cloning into '/go/src/gopkg.in/yaml.v2'...
    fatal: unable to access 'https://gopkg.in/yaml.v2/': server certificate verification failed. CAfile: none CRLfile: none
    package github.com/rubenv/sql-migrate/sql-migrate
    	imports gopkg.in/yaml.v2: exit status 128
    

    対処

    証明書によるエラーが発生している。

    apt-get --allow-releaseinfo-change update && apt upgrade -y
    

  • SAM_DOCKER_VOLUME_BASEDIR

    SAM_DOCKER_VOLUME_BASEDIR

    sam local で自動で見に行く環境変数

    sam (で立ち上がる docker)はデフォルトでそのディレクトリを見に行く作りになっている。

    https://www.slideshare.net/AmazonWebServices/local-testing-and-deployment-best-practices-for-serverless-applications-aws-online-tech-talks
    local-testing-and-deployment-best-practices-for-serverless-applications-aws-online-tech-talks-30-638.jpg (638×359)
      -v, --docker-volume-basedir TEXT
                                      Specifies the location basedir where the SAM
                                      file exists. If the Docker is running on a
                                      remote machine, you must mount the path
                                      where the SAM file exists on the docker
                                      machine and modify this value to match the
                                      remote machine.
    

    ただし、公式資料らしき記載は help とこのパワポのみなので、もう少しドキュメントを充実してほしいところ。