ゆ
Private networkの通信をSSL化することが何らかの意味のある防御策になる程度のセキュリティ侵害って具体的にどういう事例があるんだろう。例えばマシンのrootが奪取されるような場合だとHTTP sniffingを防いだところでほぼ意味がないけど……
たとえばPrivate network用にDNSが存在してる場合、SSL/TLSによってドメインの検証を強制させることでDNS poisoningへの耐性が得られるみたいなシナリオがありそう
物理的に同じマシンの中で通信してる場合はたいして意味がないが、複数の物理マシンが通信してる場合はケーブルへの攻撃が無効化できるか
ゼロトラストの前提ではプライベートな通信路の暗号化をするけど結局はコストとリスクの天秤……という話はあちこちで見るしそれは納得してるけど、肝心のそのリスクを見積もるために必要な「暗号化によって *ちょうど* 防げる攻撃」がなんなのかという情報はあまりこの文脈で語られてるのを見ないなあという
ぶっちゃけ何か防げるようなシナリオをいまいち思いつかないので、同僚が信用できないとかいうエクストリームな環境を除き気にしなくていいのでは説
いまどきダムハブとか使ってないだろうから、パケットスニファでもやられたマシンに届く通信以外はほとんどなんも拾えんだろうしねえ…
一定以上の規模の会社になると「同僚が信用できない」とか「ハブそのものを不正なものに置換される(またはハブ自体をsniffされる)」みたいなシナリオはそれなりに現実味があるのかなあという気分にはなってきています
AD と連携してクライアント証明書配って、ローカルで建ってるサーヴィスもそのクライアント証明書で認証して、だと仮に誰かのアカウントをパクってもそのアカウントのセキュリティクリアランスで閲覧できない情報は盗聴もアクセスもできない、というところでローカルでも TLS つけておくことに意義はありそう
TailscaleのNAT越え技術解説記事、めちゃくちゃ気合い入っててすごい https://tailscale.com/blog/how-nat-traversal-works
1から書き直すときは発展させやすい設計にしつつ既存のエコシステムとの互換性を維持するようにして、それで開発が回りシェアが取れるようになったら互換性を捨てにかかるというのがよくあるパターンじゃないかな
このアカウントは、notestockで公開設定になっていません。
ソフトウェア界で人類に残された最後の生産性はエコシステム間のデータフォーマットを相互変換することにある
こいつもしかして get_current_date_and_time って関数が年を返すと思ってないのか?
@teobot get_current_date_and_timeって年も返してくれるんですよ。それを踏まえて今年は何年?
ElasticSearchの練習にておロボのログを突っ込んでみようと思ったけど全然構造化してないのでパースがだるすぎる