今年のまとめ

振り返る

仕事面

色々な経験が増えた気がしています。 今までやってこなかった。というかできなかったが正しいのですが・・・・。 任せてもらえる様になって、前面に出すという形の仕事をしてました。

セキュリティ楽しい

プライベート

大きな転機がいくつかありました。 そのおかげで仕事面も順調にと言う感じです。

特に何が大きかったか

• AWSの日本のコミュニティJAWS-UGへの登壇

去年末、現在の会社に入社してから精力的にやろう！と思ってました。 それが叶ってか、うまい具合に登壇しておりまして、今年はなんと約月1回やらせていただけました。 詳しくは過去ログなりConnpassを見てくださいね。

• JAWS-UGの支部運営に参加

こちらも大きな出来事です。 せっかくなのでやりたいな。を実現してクタ目に頑張ってます。 これからも頑張ります。

• 会社で職位を作れた

実績はまだまだですが、職位を作ることができたのは、これまた一興かなと思っています。 来年は色々やりましょう。

こうやって見ると

色々突っ走ってるなって言う感じがありますが、まだまだだなと思う面も一杯有りました。 来年も宜しくお願いします。

ちょっとした告知

以前より決めていたのですが、本ブログとQiitaの位置づけを変更しようと思います。 こちらのブログは本日2025年1月1日を持って、補足記事用に。 Qiitaは、メイン記事を書くように。 という感じになります。

思い悩んでいたのですが、これには理由があります。

• はてブロで書いているのは備忘録レベルの物も多く、体裁を整えるのがマークダウンではつらいこと
• 画像を貼り付けるのに色々面倒
• Githubで連携を行いたい

と言うのが主な理由です。

では、皆様年の瀬、あと13時間で2024年も終わりますが、良いお年をお過ごしください。

勉強会でファシリテーターしてみました

前置き

以前からファシリテーターをすることに苦手意識があり、 他の方々に依頼をしていたりするのが主だったのですが、 今回は逃げられない状況もあり、やってみることにしました。

ですが、思った以上に大変な事だとやはり思い、 気持ちも感想も新鮮なうちに、皆様の力になればというので書かせていただきます。

経緯

前回、Fusicさんと弊社がコラボして「内製化支援の形」として、裏方で配信支援やタイムキーパーというのをやらせていただだき、Fusicさんからも２回目、「若手LT大会」としてやりましょうという話から開催が決定しましたが・・・・

主担当で連携していた方々の都合が悪くなってしまい、急遽自分がやることになりました。

開催日時

2024年12月18日 19時～21時

開催場所

オンライン：youtube

この時やったことリスト

• タイムキーパー
• コメント・質問やTwitterの拾い上げ（ハッシュタグのついてるもののみ)
• 登壇者紹介
• 司会進行

見よう見まねでやってみた

ファシリテーターが苦手とはいえ、登壇は結構たくさんしてきたつもりです。 それに、JAWSなどの勉強会や会社の勉強会には気軽に最近は登壇してたりしてファシリテーターさんを見てきたので軽い気持ちでやってたのですが、見よう見まねでも中々大変でしたよ。

何が大変？

• 場を温めるのが大変
  • 普段登壇するだけでは分からなかったですが、司会者は初めに「今日はこんなことをやるよ」「みんなどれくらい期待してた？」など、場のピリピリ感を和ませるという事が大事だなと言うのが改めて分かりました。
• 時間を管理するのが大変
  • 幸いな事に、今回登壇してくれた新卒のみんなは時間を気にしてくれていたですが時間を確認しているのが凄く大変で、少しあわあわしてました。
• 場つなぎが大変
  • 今回は、「登壇」→「質問タイム」→・・・・と言う感じに進めていたのですが、質問が来ないとこのQAタイムも無駄になってしまう。と言うのもあり、質問コメントやTwittergana委細も、登壇内容をしっかり聞いて、思った質問を書き留めつつ、登壇後の質問に織り交ぜてトークを繋ぐと言う事をしておりました。
• 登壇者の紹介が大変
  • 事前知識や広報的に「参加してね」をやってたので、事前にこういう人というのが分かってたので今回は良かったですが登壇者を紹介するにあたって、その人が普段何をやってるのかとかを事前に入ってないとつらいなという感じがしました。

結論

ファシリテーターは大変である。 また、それを普段からやっている皆さんは凄い人達である。 先人の人達に知識をもらいましょう。

これに限ります。

SwitchBotの通知をAWSを使ってDiscordに飛ばしてみました

そもそもなんでこんなことしてるの(理由)

Switchbotそのものは，アプリで通知が来るのですが，通知が多すぎて困ってしまう。だが，通知はそこそこに取りたい。 どうしようか。となったためにやってみました。

背景

• 通知で，スマホの電池消費が激しい
• Swichtbotのアプリ通知はほぼ全部切りたい
• 重要な所にSwitchbotは付けているのである程度通知は取っておきたい。
• IFTTTやその他連携ツールだと有償

その他

• SwitchbotにはAPIが用意されている
• このAPIでWebHookで連携出来れば，通知も可能では？
• Slackだと，過去歴は有償になるのでDiscordに飛ばす。

環境

• SwitchbotのStatus情報を取得するAPI
• DiscordのWebHookURL
• AWS環境

設計要件

• SwitchbotのAPIã‚’WebHook化(？)
• DiscordのWebhookと連携する
• Switchbotロック/Switchbot Lock Proの状態変更で通知
• SwitchbotHub2についている温度計・湿度計を定期的に通知する

githubレポジトリ

switchbot_notify

　参考にしたサイト様

Zenn 7oh様

Qiita narikakun様

Zenn Tanny様

yamamanx様

今回のソースコード

Githubにて公開中

やったこと

• SwitchbotのStatus変更を通知する先のEndpointとしてLambda Function URLsを利用
• Statusの変化に応じてAWS Lambdaを起動して，Discordへ通知
• 温度と湿度を定期的に取得・Discordへ通知するAWS Lambdaを作成して，Amazon EventBridgeからLambda関数を定期的に実行

手順

各種サービス名を省略して記載します。

1. Switchbotのアプリからアクセストークンとシークレットを手に入れる
   • iOS版のアプリであれば，プロフィール→設定→基本データ→アプリのバージョンを複数回タップとすると開発社向けオプションが出てきてトークンを確認することが出来ます。
2. 自分が管理者(Discordで通知を受け取りたいサーバ)であるDiscordのサーバからWebhookURLを取得する
   • 該当サーバのサーバ設定→連携サービス，から取得出来ます。※ブラウザでdiscordを開いて取得します。
3. Lambda実装
4. 調整
5. 動作確認
6. 完成！！

です。

実際にやってみた

Swichbotのスマホアプリからアクセストークン取得

iOS版の画像です。Android版のアプリでは未確認です。

アプリを起動して，プロフィールにアクセス，設定から基本データにアクセス後，アプリバージョンを5回タップすると出てくる，開発社向けオプションの中にあります。

1. Switchbotアプリを起動

1. プロフィール画面を表示する

1. 「設定」をタップし，「設定」画面を表示する

1. 「基本データ」をタップし，「基本データ」画面を表示する

2. 「アプリバージョン」の行を5回連打する

1. 「開発者向けオプション」が表示されるのでタップし，「開発者向けオプション」画面を表示する

2. 「開発社向けオプション」の画面で，トークンとクライアントシークレットを確認してそれぞれコピーしてください。

DiscordウェブフックURLの取得

1. 通知したいサーバの「サーバ設定」を開きます。

1. 左側の「連携サービス」を選択します。

1. 「ウェブフック」をクリックします。

1. 「新しいウェブフック」と行います

1. 「ウェブフックURLをコピー」をクリックしてコピーします。

情報取得

SwitchbotのACCESS_TOKENとSECRETを利用して，対象となるDeviceのDeviceIdの取得をしてください。

Lambdaの実装

AWSのマネジメントコンソールへログイン後，Lambdaへ移動し，Lambdaを作成します。

注意事項

このLambda関数では，http通信をするためにrequestモジュールをLambda Layerで取り込んでいます。

requestモジュールについては，KLayers様がGithubで公開している物を利用しています。

また，関数名は任意で記載してください。

実装

AWS Lambda

Githubレポジトリに上がっている

• 01.Webhook_config.py
  • HTTP通信を用いて，Web Hookへ通知を送信するためのコード
• 02.sendKeyLockStatusBottom.py
  • Switchbotロック，SwitchbotロックProの鍵の開閉状態変更を確認するコード
• 03.sendTemperaturHumidity.py
  • 温度と湿度の情報を取得，Web Hookへ通知するための送信コード
• 04.sendKeyLockStatus.py
  • 鍵の開閉状態の変更が大量に出力されるため，環境変数の制御を書き換えるためのコード

を1ファイルに対して1関数として実装します。

環境変数として利用する物を記載します。

環境変数名	値	説明
ACCESS_TOKEN	値	Switchbotのアクセストークン
SECRET	値	Switchbotのシークレットキー
DEVICE_ID	値	対象になるDeviceのId
DISCORD	値	DiscordのWebHookURL
SWITCHBOT	https://api.switch-bot.com/v1.1/devices/	Switchbotの取得するAPI
TOKEN	値	Switchbotのシークレットキー
USER_ID	値	DiscordのUserId
KEY_STATE	ロック状態の初期値	KEY_STATEの初期値です。
URL	値	DiscordのWebHookURL

となります。

AWS Step Functions

1ドア2ロックの鍵に対して，Switchbotの鍵のステータス変更が多く，軽減する必要があるためStepFunctionsにて，

01.Webhook_config.py を呼び出し，Switchbotの宛先を設定する様にしています。

AWS EventBridge

要件の通り，定期的に温度と湿度の値を送信してほしいので，EventBridgeのスケジューラを用いてスケジューリングしてください。

結果

添付のように，結果が届くようになりました。 ありがたいことです。

おわりに

解錠・施錠時メッセージが発生しちゃうので，抑制する方法は無いかなぁとちょっと思っています。

IAM Policyの書き方について考える

概要

仕事でお客様から「IAMポリシーについてちょっとお聞きしたい」という依頼で以下の依頼をもらった

1. AWS CLIによるIAM経由でEC2へは許可したい
2. GUI(AWS Management Console)には、社内IPからのみ接続を許したい
3. AWS CLIは基本的にリモート環境からはアクセス出来る(但し、実行できるCLIの中身は絞りたい)

というものでした。

出来なかったこと

本記事では全てのポリシーを載せることは出来ませんが、いくつかのポリシーで AWS Management Console へのアクセス制限以外は出来ており、 残りは AWS Management Console の制限のみだそうでした。

IAM ポリシーの考え方

AWS公式のドキュメントを見てみると下記の順番に強くされるようになっている

• 拒否
• 条件付きの拒否
• 条件付き許可
• 許可のみ

これはざっくりと書いているが、実際は文書やGoogleで自分が実際やりたい事を調べてみてほしい。

実際発生していた問題

• 条件付き全拒否ルールを入れてしまうとその拒否ルールに上塗りされて概要の3つ目が実現できない。

適用していたルール

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "${IPAddress}",
                    "${IPAddress2}"
                ]
            }
        }
    }
}

いわゆる一般的なこのIPアドレスでない場合は、全てを拒否します。 と言うルールです。 AWSの公式ドキュメントにもサンプルの記載があります。

しかし、この場合、拒否のルールのため、他の許可ルールより優先して適用されてしまうため、3つ目のCLI等の必要なアクションも拒否されてしまう。

どうしたか

前提条件として、他のルール等により、マネジメントコンソールの制限以外は制限が出来ている状態であると言うのが前提にある事を記載しておきたい。 そのため、「該当のアクション以外で、このアクション以外を拒否する」という条件付き拒否ルールにすることで解決しました。

最終的に適用を行ったルール

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "NotAction": {
          ${ActionName1},
          ${ActionName2},
          ${ActionName3}
        },
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "${IPAddress}",
                    "${IPAddress2}"
                ]
            }
        }
    }
}

このルールの場合は

• このアクション以外を拒否する
  • 条件は、このアクションじゃない場合
  • 追加条件でこのIPアドレスでない場合

となる。

つまり、 登録を行ったIPアドレス以外 で、 上記以外のActionが着たら拒否 する。 というルールです。 これで、登録外IPアドレスで「必要なアクション」を許可して、かつ、マネジメントコンソールの権限を制限できます。

感想として

こういったアクションの制限は発想の転換が必要なのかなと思いつつこう言うのって中々難しいなとは思います。 企業的セキュリティの担保、方針アクションの実施というのをきちんと行う事で正しく制御出来るAWSはそういった点ではとても便利な物だなという感想です。

また、発想の転換を行う事でより厳しい環境を作ることが出来るのは素晴らしいなということもあります。

補足事項

• 既に登録しているIPアドレス以外操作ができない別のポリシーがあります
• 設定を変更した際にミスをすると、and条件による拒否が強くなるため 許可しているIPアドレス からしか実行できなくなります（明示的拒否に当たるため）
• AWSマネジメントコンソールへの接続拒否と書いていますが、実際にはログインが行えますがポリシーにより操作拒否となります。

ご注意頂ければと思います。

AWSのコストをアラートについて

事の始まり

月初めに書くと言っていて、月末です。 今日はコストマネジメントの話です。

事の始まりは、月初めの10日くらいでした。 以下の様な感じで唐突にメールが来たのです。

私の個人アカウントでは、月間利用量が100USDを越えた場合は、アラートが鳴るように設定しています。

それにしても100USDはちょっと高すぎない？と言うので確認したところ先日ちょっと試験をしていた Amazon GuardDutyが有効になりっぱなしではないですか。 ということで、必要最低限の物に無効化して事なきを得た。というお話しです。

そこで、コストアラートはちゃんと設定しようね！というお話になります。

設定方法

まずは、マネジメントコンソールにログインします。

Billing and Cost Managementへ ※画像では、最近アクセスしたサービスと出てますが検索していただいた方が早い場合もあります。

左の予算と計画から予算を選びます。

予算の作成をクリックして予算を選びます。

テンプレート等に従って予算を策定します。

この際メールは10人まで送信出来るようなので設定しておくと良いでしょう。

やることは、これだけです。

そうすると、課金された料金を計算して今月の予測金額から予算額を超えた場合などにアラートを出してくれます。

参考までに私の設定

1予算に対していくつかのアラートが出設定出来ます。 そのため、実際のかかっているコスト・予測コスト・現在の実際かかるコスト それぞれでアラートが鳴るようになっています。

今回、この多段アラートのおかげで大きな出費にならず、早急に対処することができました。

皆様もアラート設定は忘れずに実施しましょう。 そうすることで、 起動したままにしている や、 予定してたコストより何のサービスがコストがかかるのか が事前に分かり、対処ができる様になります。

また、セキュリティ対策がしっかりしてたりすればそこまで予算が膨大化しないというとこにも着眼点を置くと、コストの試算もしやすいかもしれませんね。