OpenSSLの最新バージョンはいくつ? 今サポートされているバージョンはどれ? いつまで? とかわからなかったのでまとめる
2020/12/10 現在
詳しくは公式を読んでください
MAJOR.MINOR.PATCH )Dockerfileをベストプラクティスに沿って作るとそうなりがち
0〜1023 までのポートは well known port と呼ばれ、開放にroot権限が必要なため
8080は、非rootユーザがwebサーバを立てる時の使うポートと、IANAで定義されているため
--docker オプションを使う
serverless invoke local --docker --function hoge
--docker オプションを使うと、AWS lambda が公式に配信しているDocker でシミュレートされた Lambda 環境 ( lambci/lambda ) をつかって、serverlessをローカルで実行してくれる
lambci/lambda の解説この lambci/lambda イメージは Lambda 環境の完全なコピーではなく、一部のファイルが欠落している可能性があることにご注意ください。
lambci/lambda の docker hub
cookieにはSameSiteという属性があって、これがChrome80からデフォルトの扱いが変わった
SameSite属性が未指定の場合のデフォルト値が、None から、Lax に変更になった
ドメインAでset-cookieされた時に、ドメインBからドメインAにアクセスした時に、リクエストヘッダにそのcookieを入れるかどうかを決める属性
Strict、Lax、Noneの3つの値がある
HTTPSの場合のみcookieの送信を許可するという設定
これは、通信経路上で、cookieを盗み見 & 書き換えが行われないための施策らしいです
CSRF対策
CSRF (クロスサイト・リクエスト・フォージェリ)。異なるドメインから偽装リンク等を通じて、ユーザに意図としない動作をさせる攻撃手法
インターネット古老勢だと知っているぼくはまちちゃん攻撃が有名
mixiにPOSTするURLを偽装して掲示板などに貼る -> mixiにログインしているユーザがそのURLを踏むと、POSTが行われて、意図しない書き込みが行われる。という攻撃
で、SameSite属性のデフォルトをLaxに変えることで、他ドメインからのPOSTを規制して、CSRF攻撃を潰すのが今回のアップデートの目的(らしいです)
検討中
2020 年 3 月に 3rd Party Cookie (ドメインをまたぐcookieのリクエスト)を完全にブロックするとアナウンス
SameSite属性をNoneにした場合は、設定によって挙動が変わるらしい
SameSite=Noneを誤って、SameSite=Strictとするバグがあるので注意
これのために、Chrome80移行対応で SameSite=None に変更したい場合、サーバなりの設定でUAを見てiOSかMacOSの特定のバージョンの場合「 SameSite=None を設定しない」という処理を入れる必要がある
まだ、MacOS 10.14とiOS 12のユーザはそこそこいるはずなので...
古いChromeやAndroidのUC Browserの古いバージョンでも、 SameSite=None が実装されていないため、正しく動かないという問題もある
これもiOSやMacOSのように、UAを見て SameSite=None を入れない。という方法を取る必要がある
自前でコンバージョントラッキングをしていて、お客様のコンバージョンページにcookieトラッキングするようなタグを埋め込んでるサイトだと、 SameSite=None にしないと挙動しなくなる
トラッキング関係以外だとなにかあるのかな...?
Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する
Transport Layer Security - Wikipedia
以前はSSLと呼ばれていた。SSL3.0の後に、TLS1.0と名前が変わった
HTTPをTLSで通信をセキュアにしたものがHTTPS
2020/10/12 現在、TLS 1.0/1.1/1.2/1.3 がある。サーバもブラウザも複数のバージョンのTLSを取り扱うことができる
TLS1.0/1.1は無効化して、TLS 1.2/1.3のみを許可するのが良さそう
TLS1.0/1.1 は、暗号鍵の長さなどによって通信内容が漏洩するなどの脆弱性があり、主要ブラウザはすでにTLS1.0/1.1を無効化している
IPAもTLS1.0/1.1 を「非推奨」としている
だけど、それなりに古いブラウザのユーザはいるので、その辺はどれくらい売上に影響があるかと、リスクのバランスを取って決めたら良いのかな...? って思ってる(できる限り対応すべきではあるけど
楽天やYahoo! は2018年にTLS1.0/1.1をすでに無効化している
通信内容が漏洩すると「中間者攻撃」のリスクもあるので、できるだけ対応した方が良いと思っている
サーバとブラウザの間で通信を読み取って、改ざんしたり、情報を詐取する攻撃のこと
実際にTSL1.2以前のバージョンにおいて、中間者攻撃が可能な脆弱性が発見されている
リスナーの SSL Policy を ELBSecurityPolicy-TLS-1-2-Ext-2018-06 にすれば、TLS 1.2 以上のみ許可するようになる
デフォルトの ELBSecurityPolicy-2016-08 は TLS 1.0/1.1 も許可するので注意
モジュール random_password を使う
ほぼ同じ random_string もある。 random_password は生成結果を標準出力に出さないため、 random_string よりセキュア
resource "random_password" "master_password" {
length = 10
special = false
}
他はオプション
よく使うのは、 special (!@#$%&*()-_=+[]{}<>:? の使用可否 ) くらいか (大体 false にする )
AWS Systems Manager パラメータストアをterraformで定義したいけど、パスワードの値はterraformに持たせたくないので、仮のパスワードをひとまず入れておきたい場合などに使う
resource "random_password" "db_password" {
length = 10
special = false
}
resource "aws_ssm_parameter" "db_password" {
name = "/hoge/db/passowrd"
type = "SecureString"
value = random_password.db_password.result
lifecycle {
ignore_changes = [value]
}
}
lifecycle ignore_changes = [value] を設定することで、terraform上では、value は上書きされなくなるterraform apply 実行後、管理コンソールなどから本当のパスワードを手入力する久しぶりに使うことになったのでアンラーニングを兼ねてメモ
クラウドインフラに対するinfrastructure as code。クラウドインフラの設定をコード化して、保存/実行できる
コードにすることで、インフラの更新をVCSに残せる
VCSに残せると、変更履歴が残せる。インフラの変更をレビューしやすくなる。CIに乗せることができる。とメリットが多い
AWSとかGCPとかAzureとかいろいろ。Datadogの設定とかもTerraform化できる
肌感覚だとTerraform使っている人が多い印象。ぶっちゃけどっちでも良いと思うのでチームで決めれば良いと思う。弊社はTerraform
.tf ファイルに独自言語で記述terraform plan で変更内容を確認terraform apply で実際に変更変更されたあと、生成されたリソースのIDなどの具体的な情報が tfstate というテキストファイルに保持される。ここがポイント
VCS を用いることは非推奨とされています。これは例えば複数人が git clone して同時に terraform apply を実行してしまった場合などに、競合が発生する可能性があるからです。 tfstate は常に唯一無二のファイルがどこかに存在し、誰もがそのファイルを参照する必要があります。
Terraformでは、backendという設定でtfstateの管理場所を設定できる。AWSだと大体S3にupして管理するのが主流っぽい
ただしS3にしても、複数箇所で同時にTerraform applyが実行されると、変更がコンフリクトする可能性がある
これを回避するため、S3+何かしらのデータベースでロックして、1回に1人しかTerraform applyできないように設定することもできる(らしい)
ここまでやれば安心だけど、Terraformのためにインフラを作る必要があったりして大変
Terraform Cloudは公式のterraformのSaaS
できることは大まかに
terraform apply を実行できる)エンジニアはtfファイルを書いて、github に push すれば、あとのことはTerraform Cloudがやってくれるので大変便利
今現在、フリープランだとチーム5名まで無料なので、小規模なチームだったらとりあえず入れちゃって良いんじゃないかなという理解
無料版と有料版の違いはこちらも参照
このあたりをgithub Actionsで動作させると幸せになれるはず
Terraformのlinter。存在しないインスタンスタイプなど、Terraformではエラーにならないが、NGなものをチェックして指摘してくれる
Terraformのセキュリティスキャナー。機密情報が紛れていないかとか、AWSやGCPのベストプラクティスに違反していないかチェックしてくれる
