2024-04-28

今更ながら Google音声入力で記事を書いてみる

日常

さてタイトルの通りめちゃくちゃ今更なんですが音声で記事を書いてみています。

正直入力が早くて便利だなというのが初めの感想ですね。

しかも昨今の AI の発展の賜物かもしれないのですが音声の認識がすごく高い精度でされているのに驚きました。

Google のIME を利用して音声入力をしているんですが本当にストレスがなくスムーズに入力ができています。

ただ少し困ったことがあって、改行をしたい時にどうやって音声入力したらいいかわからなくなったりしました。

同じような悩みがある方のために今回こちらの記事に残しておきます。

結論から言うと、新しい段落と読み上げることで段落を作ることができます。通常エンターで入力するものは改行のイメージなんですが、どうやら改行は行内で改行される物のようで、例えばエクセルのセル内で改行するあの手段が、改行と捉えられるようです。

特にはてなブログでは、段落が通常イメージする改行となるようです。

でこの段落を作る際にもう一つ困ったことがあって、段落を作ると音声入力が一度解除されてしまいます。

そのため一段落ついたらマイクボタンを押してもう一度入力を受け付ける状態に戻ってもらう必要があります。

公式サイトの情報を読みに行ったのですが、思ったような情報が得られず、段落を作るたびにマイクボタンを押しています。

https://support.google.com/gboard/answer/11197787?hl=JA

良い情報をお持ちの方がいらっしゃいましたら、コメントをお寄せいただけますと幸いです。

正直、以前からインフルエンサーの方などはこのように記事を作成されるようなこともあるようなのですが、実際に話す内容をスクリプト化するならこちらの方が圧倒的に早いので、使わない手はないですよね。

やや口語体に近いフランクな文章になるので、親近感の湧く文章になって良いのではないかと思いました。

2024-04-24

リクエストフォージェリってなんなのさ

情報セキュリティ技術日常

と思ったので今回の記事を書いています。

IPAの安全なウェブサイトの作り方で紹介があるように、CSRF（Cross-Site Request Forgery）はよく聞くと思いますので、それも合わせてまとめていきます。

www.ipa.go.jp

だからリクエストフォージェリってなんなのさ
CSRFってなんなのさ？
SSRFってなんなのさ？
感想

だからリクエストフォージェリってなんなのさ

英単語に戻すと、Request Forgeryとなり、単にリクエストを偽装する。という意味になります。

Forgeryには法律用語で文書を偽造するような意味もあるようです。

Forgery - Wikipedia

こう、セキュリティ用語は英単語の意味そのものを理解する方が、記憶に定着して良いですね。

リクエストフォージェリとは全然関係ありませんが、XMLの署名のパターンにエンベロープとエンベローピングとデタッチの3種類があるんですが、このエンベロープとエンベローピングってどっちがどっちだよ！！！となりますよね。

でも、英単語に直せばあら不思議、それぞれenveloped, envelopingになって、

エンべローブ(enveloped)は、署名が文書に含まれる
エンベローピング(enveloping)は、署名が文書を含んでいる

というイメージがつきやすくなります（？）。

なぜ過去分詞形を現在形っぽいカタカナにしたのかと不思議になりますね…

グチグチ言っていても仕方ないので、閑話休題。

CSRFってなんなのさ？

CSRF（Cross-Site Request Forgery）は、ログインなどに使用しているセッションを利用して、悪意のある第三者が勝手に情報を送信するような攻撃です。

例えば、ショッピングサイトの決済を勝手にされてしまったり、インターネットバンキングなどで不正送金されてしまったりします。

各種サイトでは、CSRF対策をされているはずなので、有名サイトを利用する一般利用者からすると、そこまで怖い話でもないかもしれません。

こう言ったジャンルのサイトを運営する際には、注意が必要ですね。

どのように注意すべきかはIPAが書いてくれていますが、決済などの重要な処理をする直前に、正しい動線でリクエストされたものかを検証する手段を入れておくと良いみたいです。

SSRFってなんなのさ？

リクエストフォージェリで検索していると、見慣れないSSRF（Server-Side Request Forgery）という単語を見かけました。

こちらはサーバサイドで起こるもののようですが、詳しく見ていきます。

有名な徳丸先生のブログを参考にすると、「通常は到達できない内部のサーバに対して、Webサーバのような公開サーバから攻撃する」方法のようです。

blog.tokumaru.org

確かに、ユーザリクエストから任意のAPIにリクエストできる状態は不味そうですね…

他によく聞く、ディレクトリトラバーサルやOSコマンドインジェクションのような攻撃もSSRFの一種ということのようです。

脆弱なアプリケーションが公開されていると、恐ろしいですね…

戒めのために、ユーザからのAPIリクエストを全て通過させる門番のイラストを描いてもらいました。

強そうな門番が知らない人を通して中の人が慌てている感じがお気に入りです笑

感想

意図しないうちに何かが起こるのはやっぱり怖いですね…

パスワードを盗まれて乗っ取られるような場合も嫌ではありますが、まだ見つけやすく対処しやすい気がします。

どのようなパターンもですが、利用者の立場だと怪しいサイトには近づかないのが一番ですね。

2024-04-21

DNSレコードっていっぱいあるなぁ…

技術

連続でDNS関係の話ですが、最近少しDNSサーバも触り始めて、いろいろ設定値があるんだなぁと感心したのでここにまとめていきます。

とりあえず有名どころを押さえる
感想

とりあえず有名どころを押さえる

CDNを提供しているcloudflareの記事があったのでそれを読むことにします。

www.cloudflare.com

コピペ記事になるのも良くないので、自分なりに覚えやすい語呂合わせのようなものを作っていこうかなと思います。

Aレコード

いわゆるIPアドレス(IPv4)が引けてくるもので、いの一番でAということでしょうか。

AAAAレコード

こちらはIPv6が引けてくるということのようです。

おそらく、IPv4が32bitに対して、IPv6が128bitなので、4倍引けるからAが4つということなのでしょう。

MXレコード

メール用ということで、M（メール）をX（エクスチェンジ）するものと考えて良さそうです。

普通のハガキはエクスチェンジというよりsendするイメージなので、電話の交換局のようなイメージの方が近そうですね。

Postcard - Wikipedia

Telephone exchange - Wikipedia

TXTレコード

SPFやDKIMのようなメールのセキュリティに関連するレコードもここに書くようで、メモ書きというよりはそちらの用途の方が多そうですね。

過去記事を見ていただけると嬉しいです！

shikairo.hatenablog.com

NSレコード

権威サーバ（ネームサーバ）を示してくれるもので、上の記事でも似たようなことをしましたが、google.comでは、以下のもののようです。

$ dig NS google.com +noall +answer

; <<>> DiG 9.10.6 <<>> NS google.com +noall +answer

;; global options: +cmd

google.com. 21600 IN NS ns1.google.com.

google.com. 21600 IN NS ns2.google.com.

google.com. 21600 IN NS ns3.google.com.

google.com. 21600 IN NS ns4.google.com.

google.comの名前を教えてくれるのはns[1-4].google.comであることがわかります。

SOAレコード

start of authorityの頭文字で、あまり意味がわからないですね…

必須のレコードになるようで、これがないと始まらないし、権威を示すようなので、Authorityだけ覚えておけば良さそうです。

中には、ドット区切りでメールアドレスが書かれていたりします。

例えば、Googleでは、dns-admin.google.comがの一番左の部分を@に変えたものがメールアドレスになるようです。

$ dig SOA google.com +noall +answer

; <<>> DiG 9.10.6 <<>> SOA google.com +noall +answer

;; global options: +cmd

google.com. 16 IN SOA ns1.google.com. dns-admin.google.com. 626308993 900 900 1800 60

PTRレコード

IPアドレスからの逆引きで利用するもので、in-addr.arpaで引く時に利用されます。

shikairo.hatenablog.com

PTRは、プログラミングする場合にたまに略で出てくるポインタのことのようです。

IPが指す名前を示すという意味でポインタ…なんですかね？

感想

DNSレコードはいろいろとありますが、あまり覚えていなくても英単語を想像することでなんとかなりそうですね。

とはいえ、大文字が何個か並んでいて英単語を想像するのは辛いので、出来れば説明する文章には併記して欲しいものですね。

最後に、MXレコードのイメージを書いてもらってこの記事は終わりにしようと思います。

2024-04-17

UbuntuでDNSサーバを動かして攻撃のことも少し探ってみる

情報セキュリティ技術

前回、以下の記事でドメインとIPアドレスの関係を調べてみました。

shikairo.hatenablog.com

世の中にはこの関係をおかしくさせる攻撃もあるようなので、今回まとめてみます。

攻撃って？
構築してみる
感想

攻撃って？

DNSキャッシュポイズニングという攻撃手段があるようです。

詳しくは、DNSスプーフィング - Wikipediaを参照いただきたいのですが、ドメイン名とIPアドレスの対応を教えてくれるDNSサーバのIPアドレスがキャッシュされていない時に、偽の応答を送信してIPアドレスを騙して覚えさせるもののようです。

なお、DNSSECのような電子署名を利用して、偽の応答を受け取らないように対策されていることが多いようですので、最近はあまり身構えなくても良さそうです。

ただし、よくわからないDNSサーバに優先して接続するような場合は注意が必要かもしれません。

構築してみる

というわけで実際にDNSサーバを構築して動きを見てみようと思います。

Bindのインストール

UbuntuServerの公式に設定方法があるので、そのまま使ってみます。

https://ubuntu.com/server/docs/service-domain-name-service-dns

$ sudo apt update && sudo apt -y upgrade && sudo apt install -y bind9 dnsutils

設定ファイルを変えてみる

/etc/bind/配下に設定ファイルがあるようなので、そこをいじってみます。

/etc/bind/named.conf.optionsに、一般的なDNSサーバに問い合わせる設定を記述するようです。

ここをうっかり設定してしまうと、インターネットに存在する権威DNSサーバへの攻撃になってしまいそうなので、あえてスキップして進めます。

ただ、この時点で存在しないドメインに問い合わせるにしても、localhostのサブドメインで試せば権威DNSサーバに行かないので良いのかもしれません。

$ dig shikairo.sonzaishinai.localhost +noall +answer
shikairo.sonzaishinai.localhost. 0 IN A 127.0.0.1

このドメインのZoneを/etc/bind/named.conf.localで設定してみます。

$ cat /etc/bind/named.conf.local

zone "shikairo.sonzaishinai.localhost" {
type master;
file "/etc/bind/db.example.com";
};

読み込むファイルは例にあるようにコピーして作ってみます。

$ sudo cp /etc/bind/db.local /etc/bind/db.example.com

デフォルトだとlocalhost向けの設定になっているようです。

$ cat /etc/bind/db.example.com
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1

一旦このままサービスを再起動してみます。

$ sudo systemctl restart bind9.service

すると何も変わりませんでした…

$ dig shikairo.sonzaishinai.localhost +noall +answer
shikairo.sonzaishinai.localhost. 0 IN A 127.0.0.1

resolve.confも修正する

どうも、クライアント側のresolve.confの設定変更が必要なようなのでやってみます。

$ cat /etc/resolv.conf

nameserver 127.0.0.53
search shikairo.sonzaishinai.localhost

これでも変わらない…

と思ってよくよくみたんですが、このファイルでlocalhostの設定はされてしまっているんですね。

/etc/bind/named.conf.default-zones: default zones such as localhost, its reverse, and the root hints

なぜか動かない…

原因としては、以下のコマンドを実行しても127.0.0.53が返ってこないことかなと思うのですが、今回はここまでの調査とします。

$ resolvectl status

感想

普段何気なく使わせてもらっているDNSサーバですが、自前で作るとなるとつまづきポイントがいろいろあるように感じました。

またリベンジしてみます。

2024-04-14

名前を教えてくれるin-addr.arpaの魔法

技術日常

みなさんはドメインが実際にどのようなIPアドレスで運用されているかなど気になったことはありますか？

あまり気にする機会はないことかなと思いますが、例によって例の如く、気になったので調べてみました。

そもそもドメインとIPアドレスの関係って？
どうやってドメインとIPアドレスの紐付きを調べるの？
タイトルの呪文ってなんなのさ？
感想

そもそもドメインとIPアドレスの関係って？

DNSサーバにCNAMEとしてIPアドレスに紐づいているのがドメインというイメージです。

日常生活でイメージすると、IPアドレスが住所で、その上に立っている家の表札に書いてある名前がドメインといったところでしょうか。

厳密には違うと思うのですが、「近所の〇〇さんのお家に回覧板届けてきて」というような言い方で、具体的な住所を知らずとも回覧板を届けることができると思うので、ざっくりそんなものと理解しておけば良いと思っています。

どうやってドメインとIPアドレスの紐付きを調べるの？

例えば、以下のようなコマンドで、google.comが実際はどのようなIPアドレスで動いているのか知ることができます。

$ dig google.com +noall +answer

; <<>> DiG 9.10.6 <<>> google.com +noall +answer

;; global options: +cmd

google.com. 300 IN A 172.217.175.14

ここで、google.comの住所は172.217.175.14であることがわかりました。

IPアドレスがわかれば、そのIPアドレスの住所などを検索することができます。

タイトルの呪文ってなんなのさ？

先ほどdigコマンドでドメインとIPアドレスの紐付きを調べましたが、これを正引きと呼びます。

逆に、IPアドレスからドメイン名を引くことを逆引きと呼びます。

この逆引きをする際にin-addr.arpaを利用します。

コマンドにすると以下のようになります。

$ dig 14.175.217.172.in-addr.arpa +noall +authority

; <<>> DiG 9.10.6 <<>> 14.175.217.172.in-addr.arpa +noall +authority
;; global options: +cmd
175.217.172.in-addr.arpa. 60 IN SOA ns1.google.com. dns-admin.google.com. 624110730 900 900 1800 60

ここで、先ほど調べた住所は172.217.175.14だったのですが、逆引きをする際には逆から順に入力していくことに注意が必要です。

というのも正引きではgoogle.comというドメインを見た時に、.comドメインにgoogle.comドメインの存在を確認しにいくような、末尾から順に上位のドメインとなっています。

この上位のドメインを管理しているDNSサーバをそのドメインの権威DNSサーバと呼ぶようです。

一方で、逆引きの場合はIPアドレスを利用するのですが、IPアドレスの先頭から上位という扱いになるので、逆順にする必要があるようです。

逆引きをした際にはコマンドに+authorityと記載しているのですが、これが権威DNSレコードの部分を表示して欲しいというオプションになります。

下の画像は、道案内をしてくれるDNSサーバを描いてもらいました。

感想

digコマンドはいつも正引きでしか使ったことがありませんでしたが、逆引きでもこのように使えるんですね。

とはいえ、IPしか知らないけどドメイン名が欲しいケースがあまり思い浮かばないので、日常では利用価値があまりないかもしれませんね。

2024-04-07

Gmailからのなりすましメールってありえるんだろうか？SPFレコードってなんだろう？

技術情報セキュリティ

SPFレコードってみなさん聞いたことありますか？

自分は初めて聞きました。

ので、備忘録も兼ねてブログに記事を残しておきます。

SPFレコードって何者？
メールの送信元サーバってなりすませるの？
- メール送信のために必要な情報って？
- なりすましに気づくことってできるの？
感想

SPFレコードって何者？

Sender Policy Frameworkのことで、メールを送信しているメールサーバのIPアドレスと、実際に送信した送信元メールアドレスのドメインとの対応をDNSの情報で検証するための情報のことのようです。

いや、どういうこと？となると思うのですが、要はメール送信サーバのなりすましを検知するための仕組みに利用するもののようです。

メールの送信元サーバってなりすませるの？

普通にスマホやPCでメールクライアントを利用して送信する場合は、あまり操作できない部分ではありますが、コマンドを利用することでなりすましができるようです。

というのも、メールクライアントでは、メール送信のために必要な情報をクライアントの中で組み立てて送信してくれるので、こちらでの修正の余地が少ないですね。

一方で、メールの送信コマンドを利用してメールを送る場合は、メール送信のために必要な情報を自分で組み立てられるので、そこでなりすますことができます。

メール送信のために必要な情報って？

SMTPというプロトコルでメールを送信するために必要な情報は、おおよそ以下のとおりです。

HELO
- メールサーバとのトランザクションを開始する
MAIL
- 送信元メールアドレスを記載
RCPT
- 宛先メールアドレスを記載
DATA
- ヘッダに送信元メールアドレスを含む
- メールの本文
QUIT
- メールサーバとのトランザクションを終了する

ここで、MAILとDATAの両方に送信元メールアドレスが出てきますが、MAILの方に記載されているものは、RCPTと合わせてエンべローブアドレスと呼ばれており、実際の送信元のアドレスが記載されています。

一方、DATAに記載されているものは、データとして送信されるものなので、任意に変更することができます。

封筒で手紙を送るときをイメージすると、封筒の外側には正しい住所を書かないと届かなかったり、返送できなかったりするので、正しいものが書かれており、中の手紙はデタラメなことが書いてあっても良いといったところでしょうか。

なりすましに気づくことってできるの？

ここで、今回のタイトルのSPFレコードが出てきます。

SPFに対応しているドメインであれば、DNSサーバにSPFレコードを問い合わせることで、正しいメールサーバから送信されてきたかを判定することができます。

例えば、GMAILのSPFは、以下のように設定されているようです。

$ dig gmail.com txt

gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"

redirectが指定されているのでややこしいですが、_spf.google.com配下に登録されているものが正しい送信元メールサーバのようです。

さらに掘っていくと、どのipv4のレンジで指定されているものが正しいものか判定するところまで見つけられます。

$ dig _spf.google.com txt

_spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

$ dig _netblocks.google.com txt

_netblocks.google.com. 300 IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

ここで、~allは、softfailを示すようなので、正規のメールサーバでないものが送信していることを通知できるようです。

が、これだけでは気づくことができないので、DMARCという仕組みで、正規のメールサーバでないものが送信している場合の挙動を決めることができます。

こちらもDNSサーバに入っている設定で、_dmarcプレフィックスを付与することで取得できます。

gmailの場合は、p=rejectとなっているので、上記でfailになった時点でメールが破棄されるようですね。

$ dig _dmarc.google.com txt

_dmarc.google.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailauth-reports@google.com"

なので、gmail.com ドメインから送信されてきているメールについては、メールサーバ側での検証がしっかりとされていれば、なりすましは無い。と考えて良さそうです。

流石ですね！

ちなみに、ruaには検証がエラーとなった場合の処理が書かれていて、レポート用メールアドレスが記載されていますね。

感想

メール周りの技術にはかなりDNSの技術が関連していて面白いですね。

ドメインに責任を持たせるという考え方は、わかりやすくて良いなと思いました。

なりすましや迷惑メールの無い安全な世界になると良いのですが…

2024-03-31

VPNってどうやって動いているんだろう

技術情報セキュリティ

皆様、VPN接続は利用されていますでしょうか？

リモートワークなどで利用される技術ではありますが、実際、どういった形で接続できているのか今ひとつ理解できていなかったので、今回は記事にしてみます。

VPNって？
でもこれってどうやって繋がってるの？
インターネットVPN
リモートアクセスVPN
- L2TP/IPSec
VPNを使ってみるには
VPNサーバを構築するには
感想

VPNって？

Virtual Private Networkのことで、仮想的なプライベートネットワークを生成するもので、仮想的にLANに接続してやり取りできるようなイメージです。

例えば、外出先から自宅のVPN機器に接続することで、自宅のSMBサーバにアクセスしてファイルをダウンロードしてくるようなことができます。

でもこれってどうやって繋がってるの？

というところが疑問になり、調べてみました。

インターネットVPN

まず、VPNには様々な種類があり、専用回線を利用するものや、インターネットを利用するものがあります。

インターネットVPNは普通のインターネット回線の中に、VPNを構築してしまおうというもので、細かく分けると2種類あるようです。

IPSec-VPN

IPパケットを暗号化して通信するもので、ネットワーク層でVPNを構築するプロトコルのようです。

トランスポートモードはホスト間の1対1の通信を行う際に、トンネルモードでは主にVPN機器となるルータ間での通信を行う際に利用されるようです。

TLS/SSL-VPN

こちらはブラウザからVPN装置にアクセスして、目的のサーバがあるネットワークに接続するもののようです。

ブラウザを利用して、VPN装置のURLがわかれば接続できるので、使いやすそうですね。

参考資料

こちらの動画を参考にさせていただいて、ざっくりと理解していきました。

www.youtube.com

リモートアクセスVPN

前述のインターネットVPNを利用して、LANにアクセスすることのようです。

外出先から自宅のVPN機器に接続するようなパターンは、こちらのリモートアクセスVPNになるようですね。

L2TP/IPSec

このリモートアクセスVPNを実現するために利用するプロトコルのようです。

名前に2種類入っているようにL2TPと、IPSecを利用するものです。

L2TP/IPSecのイメージをBingに書いてもらいました。

L2TP（Layer 2 Tunneling Protocol）

L2TPは、データリンク層のトンネリングを行うためのプロトコルで、トンネル先のLAN内のサーバに対して同じLANにいるかのように通信できるようにするものです。

PPPというフレームに、IPパケットなどを含めて通信することができるので汎用性が高いようです。

ただし、L2TP単体では暗号化の機能を備えていないため、IPSecを利用してパケットを暗号化します。

2種類を組み合わせて使うのは賢いですよね。

IPSec-VPNってネットワーク層で使うものだったのでは？

という疑問が湧いてきましたが、どうやら、IPSecのトランスポートモードを利用して、L2TPのトンネルに暗号化したデータを通すイメージのようです。

そのため、IPSec自体はネットワーク層のパケットを暗号化して送信する挙動に変わりはなさそうです。

IPSecのトンネルモードでもいいんでは？

わざわざ1対1で通信するトランスポートモードではなく、IPSecのトンネリングモードを利用できそうですが、IPSecはユニキャストな通信をするようなので、ブロードキャストしたい時にL2TPで繋ぐ方が都合が良いようです。

VPNを使ってみるには

VPN Gate 筑波大学による公開 VPN 中継サーバープロジェクトという筑波大学が提供するVPNサーバがあるようなので、こちらを使う方が比較的安心かもしれませんね。

※実際に利用される際は自己責任でお願いします。

VPNサーバを構築するには

Business VPN For Secure Networking | OpenVPNのようなソフトをインストールするのが早そうです。

※実際に構築される際は自己責任でお願いします。

以下のようにコミュニティでUbuntu向けのインストールコマンドがあるのでインストールします。

apt-get update && apt-get install openvpn

https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos

その後、サーバを起動しますが、その際にはコンフィグファイルが必要となるのでダウンロードしておきます。

その他、接続に必要な鍵を用意して、起動できるようです。

build-key-serverというコマンドが用意されているようですが、すぐには見つからなかったので、単に起動するだけなら、openvpn/sample/sample-keys at master · OpenVPN/openvpn · GitHubに配置されている鍵を利用して起動してみるのも良いかもしれません（とはいえ、公開されている鍵なので、グローバルIPがバレており、ルータのポートが開放されてしまっていると繋がれてしまう気がするので危険そうですね）。

How To Guide: Set Up & Configure OpenVPN Client/server VPN | OpenVPN

単にダウンロードしてきた鍵を利用すると、以下のように権限エラーになりました。

$ openvpn server.conf
...

2024-03-30 18:26:54 WARNING: file 'server.key' is group or others accessible

...
2024-03-30 18:26:54 Diffie-Hellman initialized with 2048 bit key
2024-03-30 18:26:54 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)

chmodなどで鍵ファイルの読み取りや実行権限を実行者に絞りましょう。

すると起動を確認できました。

細かい接続などは確認していませんが、仮想環境で構築しているとはいえ、ネットワークに繋がっているマシンでサンプルの鍵で起動しっぱなしにするのは危険そうなので、起動を確認するまでにしました。

感想

なんとなく使っていましたが、技術の内容を理解して使うとなぜ安全なのかわかって良いですね！