継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

GuardDuty のマルチアカウント運用で使うべきアカウント管理機能

AWS GuardDuty

タダです.

Amazon GuardDuty(以下, GuardDuty)をマルチアカウントで有効化している場合, 各アカウントの GuardDuty のイベントを管理・運用のためにアカウント管理機能を試す機会があったので今回はその内容をまとめていきます.

GuardDuty のサービス概要

そもそも GuardDuty とは機械学習を用いたフルマネージドのセキュリティ脅威検知のためのサービスです.様々な機能がありますが,資料の37ページ以降で今回の機能が紹介されています.

アカウント管理機能の概要

本機能は GuardDuty を有効化しているアカウントのイベントを統合管理するための機能です.マスターアカウントという管理アカウントと,被管理アカウントのメンバーアカウントで構成されます.

docs.aws.amazon.com

本機能のメリット

本機能のメリットは, 各メンバーアカウントのイベントをマスターアカウントで一元管理可能です.なお,メンバーアカウント上ではメンバーアカウントのイベントのみ表示されます.マスターアカウントの管理イメージとしては下の画像のような表示がされます.

マスターアカウントのイベント管理 f:id:sadayoshi_tada:20190726202321p:plain

また,各メンバーアカウントで発生したセキュリティ脅威イベントをマスターアカウントの CloudWatch Events に統合して通知も可能なため Lambda などと組み合わせてアカウントごとに検知イベントを管理するのも個々でイベント管理するより管理負担が少ないです.

docs.aws.amazon.com

設定方法

GUI での設定方法

マルチアカウントでの GuardDuty の管理にメリットしかない本機能ですが,設定もマネジメントコンソール間で2ステップで簡単に設定可能です.

  1. マスターアカウントでメンバーアカウントに対して関連付けの有効化を行うための招待を送る
  2. メンバーアカウントでマスターアカウントからの招待を承認する.

docs.aws.amazon.com

AWS 提供されているソリューションでの設定方法

ただ,多数のメンバーアカウントの設定がある場合は以下の2つの方法があります.

1.Python スクリプトによる有効化

スクリプトの詳細は下記リンク先にあります. github.com

2.CloudFormation の StackSets 機能を使って有効化

StackSets 機能を使うためにはあらかじめ準備が必要ですが,CloudFormation テンプレートを用意する必要なく標準機能として提供されているため, Python に慣れていない方はこちらの選択肢を使うのがオススメです.ただ,StackSets 機能がないリージョンでは個別の設定が必要な点は注意です.2019年7月28日時点ではストックホルムリージョンの GuardDuty は StackSets による有効化ができないことを確認しました.

2019/07/30更新

香港リージョンでも StackSets 機能を使えないため StackSetsによる有効化はできないため,ストックホルムと香港では個別に マスターアカウント機能をする必要があります.

docs.aws.amazon.com

まとめ

GuardDuty のアカウント管理機能の概要と設定方法および運用上の注意点をまとめました.マスターアカウントでの操作が中心になる動作仕様を理解できていれば,メリットが多い機能なのでマルチアカウントでの運用を行う場合は有効化するのがオススメです.クラスメソッドさんの記事でセキュリティ被害が出た時に GuardDuty が被害検出に一役買っていたレポートが出ていたことからも GuardDuty を使う理由がなく,かつマルチアカウントでしたら今回紹介したアカウント管理機能をぜひ活用ください！

dev.classmethod.jp

「Effective DevOps」オンライン輪読会 第10回開催レポート

タダです.

challenge-every-month の Slack メンバーで 「Effective DevOps」のオンライン輪読会を毎週開催中です.

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

開催概要

方針や輪読会の概要は @kojirock さんがまとめてくださっているので参照ください.

kojirooooocks.hatenablog.com

過去の開催レポート

これまでの開催レポートは以下の通りです.

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

担当章について

今回の範囲は13~14章の途中の 14.6 までになります.14章からは4つの柱の最後の柱である「スケーリング」の話になります.

資料

資料はこちらです.

所感

  • 「ツール」の導入は「ツール」で解決したい課題や問題の所在を重要視する
  • 「スケーリング」は企業が発展・成長・進化すること
    • 組織の成功にはスケーリングの方法を知り,必要に応じて組織が拡大・縮小させていく必要がある
    • それぞれの組織で必要な行動をその時々でとる
  • 効果的なチームの規模は様々な研究が行われており,チームは大きすぎても小さすぎてもいけない

まとめ

第10回目の輪読会で扱った資料と所感を書きました.残り5章！ 最後まで走り切りましょう！

次回

次回は @kojirock さんの担当です.担当章が14章の 14-7 ~ 14.9 までになります.

AWS CDK が GA されたのでツールのアップグレードと関連情報をまとめる

AWS AWS CDK

タダです。

AWS Cloud Development Kit(以下、CDK)が GA しましたね！バージョンが v1.0.0 になりました.

公式ブログ aws.amazon.com

GitHubのリリース github.com

過去記事でいくつか AWS CDK の記事を扱っています.今回は GA されたことでバージョンがアップグレードされたので AWS CDK CLI のアップグレードと AWS CDK に興味ある方が見るべき各種ドキュメントや関連 GitHub リポジトリの情報をこの記事でまとめたいと思います.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

AWS CDK CLI のアップグレード

AWS CDL CLI は AWS CDK でデプロイするアプリや CloudFormation テンプレートを実環境に展開するために必要なツールです.このツールのバージョンアップを過去にやっていたので今回もその手順に沿ってバージョンアップグレードします.

docs.aws.amazon.com

関連記事

sadayoshi-tada.hatenablog.com

アップグレード前のバージョンは 0.33.0になっています.

$ cdk --version
0.33.0 (build 50d71bf)

ncu で確認した結果, 1.0.0 にアップグレードするためのコマンドを確認できたのでアップグレードしました.1.0.0 にアップグレードできました.

$ ncu -g aws-cdk
[====================] 1/1 100%

 aws-cdk  0.33.0  →  1.0.0

ncu itself cannot upgrade global packages. Run the following to upgrade all global packages:

$ npm -g install aws-cdk@1.0.0
$ npm -g install aws-cdk@1.0.0
/usr/local/bin/cdk -> /usr/local/lib/node_modules/aws-cdk/bin/cdk
+ aws-cdk@1.0.0
added 1 package from 1 contributor, removed 1 package and updated 28 packages in 12.756s
$ cdk --version
1.0.0 (build d89592e)

なお,初めてインストールするという場合は下記のドキュメントが参考になります.

docs.aws.amazon.com

AWS CDK の各種ドキュメントやリポジトリ

GA したのでこれから AWS CDK に触っていく人も多いかと思います.そこで確認できている各種ドキュメント情報をまとめます.

AWS ドキュメント

他のサービスと同様の公式ドキュメントです.まずはこちらから何ができるのかを確認されると良いと思います.

docs.aws.amazon.com

AWS CDK リファレンス

API リファレンスとサポートされているプログラム言語ごとのサポートページへ誘導してくれるリファレンスページです.

docs.aws.amazon.com

GitHub リポジトリ

開発のリポジトリです.改善要望はこちらから投げることができます. github.com

サンプルプログラムのリポジトリです.手始めに動かしたい人におすすめです. github.com

まとめ

GA された AWS CDK CLI のバージョンアップグレードと AWS CDK に関するドキュメントやリポジトリを紹介しました.僕も今回のリリースを受けてもっと使い込んでいきたいと思いました.締め切りになっていますが AWS CDK ミートアップが開催されるため国内の事例もこれから増えていくかと予想しています.乗るしかないこのビッグウェーブに！という気持ちで勉強していきたいですね😄

awsclouddevelopmentkitcdkmeetu.splashthat.com

CloudWatch Logs Insights で大量なログ分析も手軽に行う

AWS CloudWatch

タダです。

運用フェーズになるとトラブルシュートや定常運用時にログを確認することがよくあると思います.僕もそんな時に最近は CloudWatch Logs Insights をを使うようにしています.CloudWatch Logs Insightsは CloudWatch Logs に保管されたログに対してクエリを発行してログを表示したり、クエリの結果をグラフに出すことも可能な機能です.

aws.amazon.com

これまでは CloudWatch Logs の画面から検索することも可能でしたが,CloudWatch Logs Insights の登場によって検索で正規表現や条件をつけたりすることで検索しやすいです.今回は CloudWatch Logs Insights を使うにあたって必要なクエリの使い方と料金を整理します.

クエリについて

クエリのコマンド

クエリには1つ以上のクエリコマンドを Unix 形式のパイプ文字をで区切って定義可能で,使えるコマンドは以下の6種類です.

  • fields : 1つ以上のログフィールドを取得する
  • filter : ログフィールドを1つ以上の条件に基づいて絞り込む
  • stats : ログフィールドに対し集計計算(sum,avg,count,min,max,percentile)を行う
  • sort : 昇順,降順でログイベントをソートする
  • limit : クエリで返されるログイベントの数を制限する
  • parse : ログフィールドからデータを取り出す

参考情報

docs.aws.amazon.com

サンプルクエリ

実際にどうやってクエリを定義していいか,をすぐにわからない人も安心してください.以下のようなサンプルクエリが用意されています.CloudTrail は利用されている方も多いかと思うので,まずはこちらから始めてみるのも良いかもしれません.

  • Lambda
  • VPC Flow Logs
  • Route53
  • AppSync
  • CloudTrail
  • 一般的なログ

参考情報

docs.aws.amazon.com

利用料金

料金は,クエリごとに走査したログデータの量に対してかかるのですが,GB あたり $0.005 になります.ログ容量に応じた課金体系になっています.

まとめ

今回は, CloudWatch Logs Insights の基本であるクエリコマンドの種類とサンプルクエリ,利用料金をまとめました.今の所はログをソートしたり,filter で条件を絞ったりなどを使っていますが,もっと使いこなせてログ分析を得意になっていきたいです.

DevLoveX で カックさんの発表を聞いて感想と今後の技術ブログに活かすことを振り返る

勉強会 レポート ポエム

タダです。

6/22,23に開催された DevLoveX に参加してきました.参加したのはブログメンタリングでお世話になっていたカックさんが登壇されるため,発表を聞いてみたいと思ったからです.ネットでメンタリングしてもらったので,リアルでお会いしたかったのもありますw devlove.wixsite.com

発表資料や補足のブログはカックさんのブログで既に公開されているので,この記事ではお話を聞いての感想と今後の技術ブログ活動に活かしていきたいことを書きます.

カックさんの登壇後のブログ

記事は下記リンク先です.なお,登壇概要も合わせて引用文として載せます.

アウトプットを楽しむエンジニアが増えています．特に技術ブログを書くエンジニアが増えていますが，習慣化をして書き続けることや，読みやすい記事を書くことに課題を感じるという声を多く聞きます．そこで，技術ブログを習慣化して楽しく書けるエンジニアを増やすために「ブログメンタリング」という活動をしています．約1年半のブログメンタリング経験を整理し，技術ブログのコツとメンタリングのコツをお話します．

kakakakakku.hatenablog.com

カックさんの発表資料

発表を聞いての感想と今後の技術ブログに活かしたいこと

発表を聞いての感想

  • カックさんのいうアウトプットは「URL で誰でもアクセスできて，検索可能な情報を作り出すこと」,「Public URL-ize」と言語化されていたが自分の中でもちゃんと言語化しようとハッとさせられました.
    • 因みに,自分の中でのアウトプットの定義は「自分が理解したことを言語化もしくは図解化して第三者(未来の自分も含む)に公開すること」と定義しました.アウトプットすることが大事だと思っていたけど「どうして大事か」を考えることを飛ばしていたなと発表を聴きながら気づかせていただきました.
  • 習慣化のためには例外を作らないことの大切さを改めて痛感しました.特定期間のみバーストして燃え尽きたら元も子もないですもんね.
  • 仕事で忙しいから書けない,趣味の予定があるから書けない等の逃げ道を作らず,ブログを書く時間を作り,習慣化していくためのメンタリングで,「傾聴」と「どうするべきか」をメンティーに思考・言語化させる部分は自分が社内のメンターやっていた時にできてなかったなと反省しました.特にメンティーに言語化させる部分ができていなかったです.
  • 余談ですがカックさんにブログ書けなない理由をいうのは, @t_wada さんにテストコード書けないと言えないでしょ？って有名な AA を思い出しましたw

    🦁テスト書いてないとかお前 @t_wadaの前で同じこと言えんの？

今後の技術ブログ活動に活かしたいこと

今後の技術ブログ活動に活かしたいことが大きく3点あります.

1. ブログの専門分野の確立と役に立つ記事を作成していくこと

今僕が目指しているのが「自身の理解を整理して詳しくなる」と「誰かの役に立ちたい」部分です.これはブログメンタリングをしてもらっていた頃より意識していたことです.メンティー卒業後も自分の関心分野の記事は書いていますが,役に立つ記事のためには「ちゃんと伝わる記事になっているか」をもっとこだわっていきたいです.

2. 継続的なブログネタの整理を行う

記事を作るにあたって無計画に記事を書こうと思っても進まないためブログメンタリング期間中にネタ出しをして,そのネタ帳を今も使っています.ただ,最近ネタの棚卸しや整理を怠っていると感じたので発表を聞いた日に見直ししました.この活動を週1から見直す癖をつけていき,1.の目標の実現に近づいていきたいです.

3. ブログを楽しんで書き続けるためのセルフコントロール

改めてブログを楽しんで継続していけるよう自己管理していきたいです.ホッテントリや Twitter 等で反応をもらえるのは本当に嬉しいですし,ブログを書き続けてきてよかったと心から思えます.この感覚を継続していけるように,1.と2.の実現のために忙しくても眠くても時間を捻出し,書くための自己管理をやっていくぞと改めて思いました.

まとめ

DevLoveX でのカックさんの発表を聞いて感想と今後のブログ活動に活かすたいことをまとめました.発表を聞いてスゴいと言われる人は日頃から積み上げてきたものがあるからスゴいと唸られるんだなと感じました.カックさんは12年間ブログを書き続けてきたと話をされていました.僕は継続してまだ1年とちょっとなのでまだまだですが,積み重ねて少しでもカックさんのように近づいていきたいと思います.

最後はポエムぽくなってしましましたがw,カックさんの新規メンター募集が今かかっているので気になる方は「ブログのライザップ」と言われるブログメンタリングに応募してみてください！ブログをもっとよくしていきたいと思っている人は必見です！

関連記事

カックさんのブログメンティー期間を振り返った記事 sadayoshi-tada.hatenablog.com

ブログメンティー同士で集まった時のレポート記事 sadayoshi-tada.hatenablog.com