重要な通知にはSlackを使いたいけど、Chatbotではアカウント名が表示されずにわかりにくいChatbotではアカウント名が表示出来ない(2022年10月15日確認時)ため、運用するAWSアカウント数が増えれば増えるほど、アカウントIDから判断するのが大変!といった、かゆいところに手が届いてない方向けに情報を発信していきたいと思います。Chatbotを使ってSlack通知をしてみたやり方を考えてみるJSONを考えるアカウント名取得するにはアーキテクチャを簡単にするあとがき一緒に働く仲間を募集していますChatbotを使ってSlack通知をしてみたChatbotを活用したChatOpsという記事もAWSさんが以下のように書かれています。重要度が高い通知については、「赤色」になっていたり非常にわかりやすいと思います。(本来であればアカウントIDが表示されているところは、マスキングさせてもらっています)ただ1点、アカウント名が表示されていないですよね。Slackで通知されるアカウントIDからアカウント名を答えられるように、全てのアカウントIDとアカウント名の紐づきを覚えればいいじゃないか、ごもっともです........。一部のチームからもSlack通知時にアカウント名表示をして欲しい、、、という改善要望もあったので、Slack通知時にアカウント名を表示させたいと思うようになりました。やり方を考えてみるChatbotではアカウント名を表示させることが出来ないことを確認しています。(2022年10月15日時点)すごく手軽に設定が出来て良いサービスなのですが、断念せざるを得ない状況です。URL)の仕組みで通知が出来ないか検討をしてみました。この構成なら出来そうだな、と思いながら色々と大変なポイントがあったので、この後紹介をしていきたいと思います。JSONを考えるSlackに通知するAWSサービスの対象として、弥生では「GuardDuty」、「SecurityHub」を対象としています。今回は「GuardDuty」についてSlack通知するためのJSONを考えてみようと思います。「GuardDuty」のJSON形式の例としては以下のような記事があります。DevelopersIO上記の記事で紹介されていたGuardDutyで検知された際に出力されるJSONの各情報から、必要なものをSlackの通知フォーマットへ合わせる必要があります。Slackへ通知する際のフォーマットは以下で紹介されています。Slackこれだけではわかりにくいと思いますので、ざっくりまとめると以下のようになります。]}このJSONの形式が決まると、SlackへChatbotのように成形された通知が送信出来るようになります。アカウント名取得するにはここまででChatbotに近い形式で通知が行えるようにするSlackのJSONフォーマットが決まりました。元々の問題だった、「アカウント名の取得」が解決出来ていません。この問題を解決するには、lambdaで以下の記述をすることでアカウント名を取得することが可能です。boto3.client(organizatinos).describe_account(AccountID)これでアカウント名を表示させて、Slackへの通知が可能だ!、と浮かれていましたが壁が立ちはだかりました。弥生では「ControlTower」というAWSのサービスを使用して、マルチアカウント環境を構築しています。GuardDutyの検知情報は「Audit」というアカウントに集約させています。Account」でlambdaのコマンドを発行する必要がありました。アーキテクチャとしては以下のようになります。Account」のEventBridgeへ連携させます。Account」のlambda関数でアカウントIDからアカウント名を取得し、GuardDutyのJSONをSlack通知フォーマットへ合わせて通知する、といった流れになります。「GuardDutyをSlackへ通知したい」だけなのに、2つのアカウントを使って実装しなければならない、、、なんか仰々しくないでしょうか?え?そんなことない??私はこれが嫌でさらにアーキテクチャを検討することにしました。アーキテクチャを簡単にするアーキテクチャを簡単にしたい!ということで、壁にぶちあたりましたが、AWSの機能アップデートで良さそうなものを見つけました。Organizationsの一部権限を委譲出来るというものです。これで「Audit」アカウントに必要な権限を委譲することで、簡単に出来ると思いました。権限移譲を試してみた結果、以下のようなアーキテクチャで実現することが可能となりました!アーキテクチャ改良後え?あまり変わってないw?元のアーキテクチャと良く見比べてみてください!私としてはアカウントを跨がずに実現が出来るようになった、という点がすごく良かったと思っています。あとがきAWSは便利で良く活用をさせてもらってますが、それでも自社の環境下で使うには、「ここがイマイチ」という部分もあるかと思います。色々なサービスを組み合わせれば、実現不可能なものは少ないとも思いますが、そのために複雑なアーキテクチャにしてしまっては運用保守が大変だと思っています。運用保守を楽にしていくためにも、アーキテクチャを簡易なものにしていく、そのために各AWSサービスをうまく活用してみたり、各機能のアップデートをチェックして、活用できるものがあれば取り入れて改修をする、といったことも重要なんだな、と感じた対応でした。2023の5日目の記事です。弥生は第23回Quesに協賛します。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。