IFTTTの基本
家にAmazon echoがある。
今まで音楽流したりニュース聞くくらいしか使ってなかったけど
せっかくソフトのエンジニアなわけだし、色々いじってみたい。
と思い、とりあえず基本の”IFTTT”を登録して見ることに。
IFTTTというサービスは
ある動作をトリガーに、ある動作を実行する、といった
２つのサービスをつなぎ合わせるサービスである。
例えば○○といったLINEがきたらGmailに内容を転送する、といったような。
今回実現したものは
Alexaに”ライン”と伝えると、スマホにLINEが届く、といった内容のもの。
初歩の初歩。
まずはIFTTTの登録
登録したら、MyApplets->NewAppletを選択
上の画像の「＋this」の部分をクリック。
この部分で動作のトリガーとなる処理を登録する。
今回だったら"Amazon Alexa"を選択
Alexaの中でもトリガーの種類は色々あって、
TODOリストをきっかけにするものだったり、買い物リストをトリガーにするものだったり？
今回はシンプルに
を選択。要はAlexaに何か言った時にトリガーが発生する。
次にトリガーを発生させるフレーズを登録。
今回はテストなのでシンプルに”ライン”とする。
これでトリガーの設定が完了。
次に、このトリガーがかかった時の動作を登録する。
先ほどは「+this」を登録したので、次は「+that」をクリック
今回はLINEを送るようにしたいので、LINEを選択。
LINEのアクションは１種類しかないようなので「Send Message」を選択
次にメッセージの内容を設定。
今回はシンプルに”テスト”とだけ、送信するようにする。
これで設定は終わり。簡単。
あとはAlexaに呼びかけるだけ。
ここで１つ注意が必要なものは、呼びかけ方。
正解の呼びかけ方は
「Alexa ラインをトリガーして」
これが結構シビアで、順番を変えたりするとAlexaが反応してくれない。
そもそも「トリガーして」ってつけるのがダサい。
Google homeだと自然な呼びかけでできるらしいけど、Alexaはまだできないそう。
やろうと思えばできるそうだけど、色々とめんどくさそうなので、時間があったらやってみよう。
そんな感じで、正しく呼びかけてあげると、無事にラインが届いた。
ということで、お試しでIFTTTを使ってみました。
簡単だとは聞いていたけど、思っていた以上に簡単。
もう少し使いこなして、家電も操作できるようにして見たいと思います。
以上
Win10のバージョンについて
今までOSの知識として、例えばWin10であれば
32bitか、64bitか
HomeEditionか、Professionalか
くらいの知識しかなかった。
OSもバージョン管理がされているらしく
今であればRedstone3(1907)というバージョンらしい。
が、どうやら年に二度ほど大きなアップデートがあるとのこと。
直近で行われたアップデートが
”Fall Creators”
その前は
”Creators Update”
何が変わったかはわからん、たくさん変更があるみたい。
けど大幅な変更があるみたいなので、アプリ作る場合は検討する必要がありそう。
SSLとSSHについて
なんとなくセキュリティに関するワードなんだろうな、と思ってはいたけれども
そもそも何かをしっかり理解できていなかったし、違いも分っていなかった。
●SSL(Secure Sockets Layer)
SSLの目的としては２つ
①通信内容の暗号化
②サーバーが安全かどうかの証明
まず①について
amazonとかで個人情報を入力する時など、暗号化せずに平文で送ってしまうと
悪い人に見られて悪用されてしまう。
逆にamazonなどで購入履歴などの情報を見るときも暗号化せずに受診すると
悪い人に見られて悪用されてしまう。
これらのことを防ぐために、通信内容を暗号化する必要がある。
方法としては、クライアントがサーバーに接続を要求した時に
サーバーからクライアント側に対してサーバ証明書を送付する
そのサーバ証明書の中に公開鍵が含まれており、その公開鍵を用いて共通鍵を暗号化
サーバー側ではその共通鍵を秘密鍵を用いて復号。
これによってクライアント側、サーバー側で共通鍵を持つことができる。
よって①の目的である通信の暗号化が実現できる。
これはよくある暗号化の話。
では次に②について。
クライアント側からすると、そもそもサーバーが安心できるサイトなのかどうかわからない。
たとえ送った内容が暗号化されても、送り先が悪い人だったら意味がない。
そこで、これから接続する先が信頼できるサイトなのかどうかを判断する事が②の目的。
①の時にも説明したが、サーバに接続を要求した時にサーバ証明書が送られてくる。
この証明書を頼りにサーバー側が信頼できるサイトかどうかを判断する。
たとえサーバ証明書があったとしても、その証明書が信頼できると話限らない
そこで、その証明書が信頼できる。と保証してくれるのが認証局。
ただ、その認証局が本当に信頼できるかわからない...といって堂々巡りになってしまう。
ただ、一番大元をたどるとルート証明書を持つ認証局までたどり着く。
このルート証明書はあらかじめブラウザに登録されているため、確実に信頼できるといえる。
なので最下層の証明書から、中間の証明書(中間CA証明書)をたどり、最上位の証明書(ルート証明書)までたどり着き、最下層の証明書が信頼できると判断可能となる。
この証明書を元に、ユーザーは信頼でいるサイトとして判断し、接続が可能となる。
なお、SSL証明書がある場合はURLが「https」から始まる。
なお、このSSL証明書にも色々と種類があり、信頼度などから値段も様々である模様。
●SSH(Secure Shell)
SSHもサーバーとクライアント間の通信をより安全にするためのもの
SSHの主要な認証方式としては、パスワード認証方式と公開鍵認証方式がある。
パスワード認証方式はセキュリティ的に脆弱らしい、
公開鍵認証方式のみ詳しく解説。
やりたいことは
①クライアント→サーバー側の保証
②サーバー→クライアントの保証
①に関しては、クライアントが今から接続するサーバーが本当に接続しても大丈夫かを判断するたものもの。
サーバーにSSHで接続すると、サーバーが公開鍵を渡してくれる。
この鍵を見て、以前登録したものと同じであるならばアクセスを許可する。
(登録済みでないのであれば、許可するかどうかをこのタイミングで判断する。)
②に関しては
クライアント側でopensshなどを用いて、ペアの共通鍵と秘密鍵を作成する。
公開鍵をサーバーにあらかじめ渡しておく。
クライアント側は秘密鍵の方で暗号化し、それをサーバーに送信。
サーバーは公開鍵で復元することによってクライアントがあらかじめ登録されたクライアントかを判断する事ができる。
どちらも暗号化して、通信を安全に行うためのもの。
なぜならば、SSLはサーバー側がSSL証明書を一つ持てばいいことに対して
SSHは通信路１つに対して、秘密鍵・共通鍵のペアが１つ必要なため。
ただSSL証明書は仕組みが複雑で運用も大変なため、あまり人数が大奥ないのであればSSHの方が楽みたいです。
使い分けが必要ですね。
内容に誤りがある可能性もあるので、その場合はご指摘ください。
初回からやや長めになりましたが、以上です。
はじめに
組み込みエンジニアです。
その日に学んだことをアウトプットしていきます。
