2020-05-13

VSCodeでEmmetを設定する

Tips

Emmetとは

HTML/CSSを記述する際に簡易的な記述だけで自動保管してくれるイケてるやつ

VSCodeでの設定方法

Ctl + Shift + Pでコマンドパレットを表示

(Macの場合はCommand + Shift + P)

コマンドパレットにjsonと入力

基本設定：設定（JSON）を開くを選択

Setting.jsonに以下を記載

{
    "terminal.integrated.inheritEnv": false,
        // スペースを表示
    "editor.renderWhitespace": "all",
    // emmetの言語設定を日本語に
    "emmet.variables": {"lang" : "ja"},
    // emmetをタブキーで実行
    "emmet.triggerExpansionOnTab": true,
    // タブをスペース2個に変更
    "editor.tabSize": 2,
    // 折り返し
    "editor.wordWrap": "on",
}

2020-04-25

『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』から学んだ覚えておきたいこと

読書 AWS

こんにちは。
AWSの技術本として佐々木拓郎さん(@dkfj)が
AWSにおけるアカウントセキュリティに関する本を出版されていたので
拝読させて頂きました

感想

AWSにおいてセキュリティにまつわるサービスは非常に多岐に渡ってリリースされており
重複と思われるような機能も存在する中で各サービスの特徴だけでなく使い分けに関する考え方などもまとめられており非常に勉強になりました。

また、マルチアカウントの運用という観点で本の大部分が記載されているAWS本は珍しく
現場でマルチアカウントを運用している私としてはその点でもとてもありがたかったです。
実際に手を動かしてみるというチャプターもあり、AWSの基本知識は必要ですが
前提知識を抑えた初学者にも優しい構成になっているように感じました。

備忘用

以下は完全に個人的に覚えておきたい本の内容を記載していきます
読みながらまとめたものを貼っただけなので、可読性完全無視です。興味がある方は、複数のAWSアカウントの運用者は後悔しないと思います。
ぜひBOOTHで購入して読んでみてください。

booth.pm

Macie

概要さえよく知らなかったAWSサービス
S3バケットに保存されたデータを検出、分類、保護する機械学習サービス
CloudTrailと連携してどのユーザーからどんなAPIアクセスがあったかを分析することもできる
アクセスパターンの分析によって、「普段そのバケットを利用しないユーザーが大量のソースコードをダウンロードしている」ことを検知して
CloudWatchでアラートに連携するということも可能

Organizationsが作るロール

Organizaitonsから作成したメンバーアカウントのIAMロールに「OrganizaitonAccountAccessRole」が作成される
→Organizaitonのマスターアカウントから各メンバーアカウントを管理するためのロール
【運用上の注意点】
マスターアカウントのユーザーからスイッチしてログインすることができる
※信頼関係の設定で「マスターアカウントのユーザーすべてからスイッチできる」ようになっている
【対応策】

マスターアカウントには必要最小限のIAMユーザーのみしか作らないようにする
OrganizaitonAccountAccessRoleの信頼関係を絞る（筆者はこちらを推奨）

SecurityHub

複数のアカウントの状況を一括してモニタリングするサービス
様々なAWSサービスからのセキュリティリスク情報を収集

Inspector
FirewallManager:複数のAWSアカウントのWAF/Shield/SGを一元管理できる
IAMAccessAnalyzer:外部公開が可能なAWSサービスが不要に公開されていないかを確認することに重点を置いたサービス ※IAMロール/KMS/SQSを対象にすることが可能（ConfigRulesとの比較として知らなかった点）

統合サービスSecurityHubの位置づけ

GuardDutyで検知した脅威のCloudWatahEventsへの連携方法

AmazonGuardDuty→SecurityHub経由でCloudWatchEventsへの連携
- SecurityHubFindings
  - Imported
  - CustomAction（人間が一度検知内容を確認して後続の処理を呼び出すことを選択できる）
  - Results
- AWSAPICallviaCloudTrail
AmazonGuardDuty→CloudWatchEventsへ連携

【使い分けの考え方】←超勉強になった
GuardDutyから直接対処する→リアルタイムで自動的に防御すべきもの
SercurityHub経由で対処する→リアルタイム性が低く内容を人間が判断すべきもの

SecurityHubにはコンプライアンスへの準拠状況をチェックする機能もある
現状は以下を基準にチェックする
CIS AWS FoundationsBenchmarkv1.2.0
PCI DSS v3.2.1
【準拠状況へのマインドセット】
必ず100%にしなければいけない×
基準を満たしていない部分を把握して、どういった対策が必要かどうか調べた上で対策するかどうかを判断する○

※SecurityHubは今後セキュリティ管理の中核として重要になっていくのでとりあえず設定して稼働しておく方がベター

通知

【通知設定の考え方】
重要なものや単なるお知らせ程度のものまで、同じように受信して対応していると運用はすぐに破綻する

対処の重要度ごとに通知方法を変える

重要度が高いものほど、同期性が高いものにする
重要度が低いものについては、メール等の同期性が低いものにする
とりあえず通知ではなく、送らずに済ませられないかをまず考える

通知は人間の判断・対処が必要なものを送る
人間の判断が不要なものは通知しない
自動で対処可能なものは、通知なしで自動対処
自動処理したものは、結果をわかるようにだけする

対応と復旧

AWSではAPIを通じて自動で元の状態に戻すことは簡単なので、復旧を自動化することを目指す
ただし、最初から復旧を作りこむのではなく、実装コストとメリットを見極めて自動化をおこなう
* 有効なサービス * Lambda * CloudFormation * SSM Automation EC2 →　ConfigRules(ルールから外れた設定の検知) →修復アクションの呼び出し→AWS SystemsManager(Automation)で自動修復

参考URL

【新サービス】機械学習を使って不正なアクセスパターンを検出、対応するAmazon MacieがLaunch。 | Developers.IO

IAM Access Analyzerと既存の機能を比較してどう使っていくか考察してみた #reinvent | Developers.IO

2020-04-25

AWSConfigルールのトリガー指定

AWS AWS Config AWSSysOps対策

AWS SysOpsアソシエイトの対策としてAWS Configルールのトリガー指定について勉強したので備忘としてまとめます

AWS Config

AWS ConfigはAWSアカウント内のAWSリソースの設定情報などを統合的に参照できる"痒い所に手が届く"系のAWSサービスです
「設定ストリーム」で、AWSリソースの設定変更履歴をタイムライン的に参照できたり
各セキュリティグループがどのEC2に紐づいているとかが「リソース関係」ビューで確認できたりします

AWS Configルール

AWS Configでは設定履歴を参照できるだけでなく、AWSリソースが"適切に設定されているか"を評価してくれる機能もあります
その評価基準を作成するのに使用するのがAWS Configルールです

例えば、以下のようなルールを作成します

IAMユーザーにはMFAを設定する
EC2のボリュームは暗号化する

トリガーの指定

上記のようなルールを作成した上で、「どのタイミングでそのルールを評価するのか」を"トリガー"で設定します

トリガーのタイプは2種類

1. 設定変更トリガー
特定のタイプのリソースの作成・変更・削除などをトリガーに評価します
以下をトリガーに指定可能です * リソースタイプ * リソースタイプとリソースIDの組み合わせ * タグのキー/バリューの組み合わせ * 記録対象のリソースの作成・変更・削除

2. 定期的トリガー
読んで字のごとく「何時間おきにルールを評価するか」を設定します

設定レコーダーに注意

前述の通りAWS ConfigはAWSリソースの設定情報を統合的に記録・管理・参照できますが、これは「設定レコーダー」の機能によるものです
設定レコーダーを有効にしていることで、設定情報をAWSリソースの更新内容を記録してくれることで
AWS Configの各機能を利用することができます
で、この設定レコーダーはデフォルトで起動しているんですが、停止することもできてしまいます

設定レコーダーをオフにすると トリガータイプの設定変更トリガーは実行されません

※定期的トリガーは実行されます
誤って停止してしまうと必要なConfigルールの評価が検出できなくなってしまうことがありますので
少し注意が必要です

2020-04-25

AWSConfigルールのトリガー指定

AWS AWS Config AWSSysOps対策

AWS SysOpsアソシエイトの対策としてAWS Configルールのトリガー指定について勉強したので備忘としてまとめます

AWS Config

AWS Configルール

例えば、以下のようなルールを作成します

IAMユーザーにはMFAを設定する
EC2のボリュームは暗号化する

トリガーの指定

上記のようなルールを作成した上で、「どのタイミングでそのルールを評価するのか」を"トリガー"で設定します

トリガーのタイプは2種類

設定レコーダーに注意

2020-04-18

AWSConfigルールのトリガー指定

AWS AWS Config AWSSysOps対策

AWS SysOpsアソシエイトの対策としてAWS Configルールのトリガー指定について勉強したので備忘としてまとめます

AWS Config

AWS Configルール

例えば、以下のようなルールを作成します

IAMユーザーにはMFAを設定する
EC2のボリュームは暗号化する

トリガーの指定

上記のようなルールを作成した上で、「どのタイミングでそのルールを評価するのか」を"トリガー"で設定します

トリガーのタイプは2種類

設定レコーダーに注意

2020-03-21

S3 Glacierのボールトロック

AWS S3 AWS SOA対策 S3 Glacier

昨日の記事にてAWS SOAに向けた勉強に少しばかりエンジンがかかった気がしています。

コロナウィルスで外出を控えている方が多いのを狙ってWhizlabsから50%OFFクーポンが届いていたので
「え～～い！やったるわ～！」とAWS SOAの問題集を購入しました（1000円くらい）

www.whizlabs.com

これから毎日少しずつ勉強時間確保して、4月上旬くらいまでには取りたいなと思っています。

で、今日の本題なんですが、SOAの問題集を解いていてS3 Glacierについて知らない概念があったので
AWS SAAのおさらいがてらS3 Glacierについてざっと大事な要素をまとめておきたいと思います。

そもそもS3 Glacierってなに？

データのアーカイブ/バックアップ用に最適化されたストレージサービスです。
基本的にほとんど参照する必要はないが、残しておかなければいけないデータを格納しておく用途を想定されています。
○○ヵ月経過したら参照する頻度が下がるが残しておかないといけないデータが格納されている
S3オブジェクトにライフサイクルを設定しておくことで、自動的にS3Glacierにデータを内部的に移動するなどといったことが可能で
S3よりデータ保持にかかるコストが安価です。その代わり頻繁なデータの取り出しなどは基本的に想定されていないので
データの取り出しには長時間かかり、コストも高いので、使用する際は注意が必要です。

S3 Glacierのデータモデルの主要概念

上記のように基本的にはS3とセットで使うというくらいにしかGlacierの知識はなかったのですがこの機会にGlaicerを使う上で出てくる用語くらいは抑えておこうと思います。

アーカイブ

写真・動画・ログファイルなどの任意のデータのこと（S3でいうところのオブジェクト）
アーカイブには一位のIDとオプションが割り当てられます

ボールト

アーカイブを格納するコンテナ（S3でいうところのバケット）

ジョブ

アーカイブに対する処理をジョブと呼びます。アーカイブをダウンロードする際は
まず、ジョブでアーカイブを取得し、ジョブの出力結果をダウンロードするという流れになります

通知設定

S3 Glacierのアーカイブに対するジョブ実行は完了まで長時間かかるため完了通知機能をサポートしています
ジョブの完了時に、AmazonSNSに通知を送信するようにボールトを設定できます

S3 Glacierのボールトロック

S3 Glacierに格納されているアーカイブデータに対して、書き込み処理ができないように
ロックをかけるオプションがボールトロックです
S3 Glacierに格納されているデータはその性質上、改ざんされないようにプロテクトする必要があるケースが多いと思います

ボールトに対してボールトロックポリシーを設定することで
「Write once Read Many」などコンプライアンスに即したデータ保護を設定することができるようです。

ボールトロックをかけるまでのステップ

ステップ1

ボールトロックポリシーをボールトに関連付けます。
これによってロックが「InProgress」の状態になり、ポリシー内容が適切か検証できる状態になります。
InProgress状態になった際に、ロックIDが払い出されます。（ロックIDの有効期限は24時間）

ステップ2

ステップ1の検証の結果、ポリシー内容が問題なければ、ロックIDを使用してロックをかけます。
ステップ1でポリシーに不備があれば、ロックを中止することが可能です。

おわりに

S3 Glacierについて、超基本的なことをおさらいしました。
正直、S3Glacierって実際にAWSを使っていてもほとんど意識しないんですよね（ユースケース的に当然ですが）
ボールトロックという機能については、コンプライアンス要件が厳格なプロジェクトは使用するケースがあると思うので
覚えておいて損はないですね。

参考

Amazon S3 Glacier とは https://docs.aws.amazon.com/ja_jp/amazonglacier/latest/dev/introduction.html

Amazon S3 Glacier のボールトロック https://docs.aws.amazon.com/ja_jp/amazonglacier/latest/dev/vault-lock.html

2020-03-20

スポットインスタンスのスポットブロック機能が良さげなお話

AWS

今年の年初にプロジェクトチームのTeamsでAWS資格の「SOAとSAP取るっす」とか宣言しちゃったものの

すでに3月終わりそうな段階で何も手を付けていないので

「そろそろ、やばいな～」という気になり

やる気が漲るように願いを込めて久しぶりにGoogle先生に

「AWS　SOA　勉強」と投下するところまで来ました。（拍手！！）

去年、CLP・SAAを取得したときもそうでしたが

猛者たちの合格体験記を読むとなんだか勉強した気分にとりあえずなれるので

気を紛らわすのにちょうど良いですね

そんな感じで合格体験記を読んでいたのですが

さすがにサンプル問題くらいやってみるかと思い、AWS公式HPのサンプル問題解いてみたところ

スポットインスタンスのオプションに「こんなのあるんだ！」という気づきがあったので

備忘録的に残します

ちなみにこの問題と別に1問間違えて正答率80%だったので確実に今受験したら落ちますね。（サンプル問題は実際の試験の比にならないくらい簡単なはず）

まず問題は以下

f:id:nogasalog:20200320102036p:plain — samplequestion

S3に保存されている売り上げとかのデータ集計の夜間ジョブを実行するのにコスト最適なソリューションを問われています

現行は複数のオンデマンドインスタンスで実行されているけど2時間以内で完了するジョブなので明らかにコストかけすぎですね

夜間ならいつ実行されても良いけど、ジョブが失敗したら最初から再実行する必要があるというのが要件として記載されています

「夜間ならいつ実行されてもいいならスポットインスタンスでええやん！」と画像の通り"C"を選んだのですが

見事に不正解でした

正解は"B"

f:id:nogasalog:20200320102911p:plain — seikai01

この「スポットブロック」って概念はまったく知らなかったので少し調べてみました

スポットブロック機能とは

スポットインスタンスで起動するインスタンスに「継続時間」を事前に定義することで

スポットインスタンスの起動時点から一定の時間インスタンスを中断させることなく起動させておけるオプション機能

そもそもスポットインスタンスって？

事前に"スポットインスタンスリクエスト"で以下を定義しておきます * スポットインスタンスに支払う上限料金 * スポットインスタンス数/インスタンスタイプ

スポットインスタンスの価格はスポットインスタンスに対する需給状態によって時間ごとに変動しています（スポット価格）

このスポット価格が設定した上限金額以内のときに事前設定したスポットインスタンスリクエストの通りに

インスタンスが起動します

オンデマンド料金と比較して、かなり安価にEC2を利用できる上に上限金額を設定できるので

コスト管理もしやすいという特徴があると言えると思います。

ただ、このスポットインスタンス、設定した上限金額をスポット価格が超えてしまうと

自動的にインスタンスを停止してしまうのです。

スポットインスタンスのコンセプト的には納得の動きなのですが

正直、スポットインスタンス使いづらそうだな～という印象でした

実行時間制御ができるスポットブロック機能

この途中でインスタンスが停止してしまう問題を解決してくれるのが

先に紹介したスポットブロックオプションです。

オプションとしてスポットブロック（継続時間）を1～6時間の間で1時間単位で指定することで

スポットインスタンスの起動からインスタンスを実行する時間を固定できます。

ユーザーが手動でインスタンスを停止するか、スポットブロックで指定した時間が経過するまでインスタンスが中断することはありません。

しかも価格はインスタンス起動時間からインスタンス終了まで固定！

ユースケースは？

冒頭に紹介したサンプル問題の通り

いつ実行されても良いが、途中で処理が終わってしまうのは困る

処理にかかる時間がある程度予測できる

ジョブ実行サーバーのコスト最適化が図れます

これがあるならスポットインスタンスを使用するハードルかなり下がる気がするので頭の片隅に置いておこうと思います

サンプル問題解いてみてやはりちゃんと勉強必要そうなので

SAA取得したときにお世話になったWhizLabsで勉強しようと思います。。。

https://www.whizlabs.com/

参考

スポットインスタンスの仕組み https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/how-spot-instances-work.html
スポットインスタンスの継続時間の定義 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-requests.html#fixed-duration-spot-instances
合格体験記 10日で大丈夫！AWS認定SysOpsアドミニストレーターアソシエイトの勉強法！ - Qiita