勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者

DevSecOps｜技術顧問｜旅＆ファッション＆コーヒー＆ワイン好き｜#ETH 推し｜スキルセット→

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

日本という国は改めて考えてみると本当に天国みたいなところだと思うんですよね。

・安全で衛生レベルも非常に高い(水道水が普通に飲める時点ですごい)。
・公共も民間もあらゆるサービスの平均的な質が高い(クール宅配便が数百円で利用できるとか凄すぎるｗ)。
・医療レベルが高いのに医療費は十分にリーズナブル(国民皆保険のおかげ)。
・ご飯がほぼ何でも美味しい上にリーズナブル。
・ほとんどの人が基本的に穏やかで親切。
・自然がいっぱい＆四季があるので各地域の各季節それぞれの風景や行事を楽しめる。
・漫画/アニメ/音楽/映画などの国産の大衆向けコンテンツの質と量が凄すぎる。
・(特に都市部は)公共交通機関と徒歩でほぼどこでも行ける。
・(特に東京は)色々な娯楽がとてつもなく充実している。
・ビザ無しで大抵の国に旅行できる。

もちろんよくない点も多々あるとは思いますが、不満ばかり言ってないでこういう国に生まれた幸運をフルに活用して思い切りエンジョイしないと絶対に損だよなあと思う昨今であります😄

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

ここ最近のサイバー攻撃の被害激増により改めてセキュリティエンジニアという職種が注目されていますが、セキュリティ分野「だけ」を専門にするかどうかはよく考えてみた方がいいとは思いますねー。

例えば小〜中規模ITベンチャーさんとかだと、セキュリティだけの作業は定常的な業務量がそこまで多くならないので、セキュリティエンジニアは単体の職種として成立しずらいんですよね。(バックエンドやインフラの担当者がセキュリティ業務を兼務するケースが大半であり通常はそれで十分)

ある程度の規模の事業会社さんとかでも、セキュリティ周りの定常的な作業量はそこまで大きくならないので、情シスさんがベンダーの協力のもと他の業務をやりながらセキュリティ周りも兼務するという感じになるのが一般的なので、ここでも単体の職種になりづらいわけです。

なので必然的にセキュリティエンジニアはセキュリティ専業の企業さんで働くことが多くなるとは思いますが、それはつまりフロントエンドやバックエンドと比較して「活躍できる場所の選択肢がかなり限定される」ということになるわけで。

そして全体の求人数がそれほど多くならない＆働く先の企業が限定されがちということは「業務委託案件もかなり少ない」ということなので、フリーランス志向の方にはあまり向いていないということになりますし。(ここら辺はフリーランス案件サイトとかで確認するとすぐ分かると思います)

なのでセキュリティ方面に関心のある若手の皆さんへのおすすめとしては

・まずはバックエンドやインフラを専門にしてそれらの職種で十分なキャリアを確立しつつ、そこにセキュリティ方面の知識や経験をプラスしていく

・十分キャリアが安定した後で、それでもどうしてもセキュリティ分野を単体で深く掘りたくなったらセキュリティ単体のエンジニアへのジョブチェンジを検討する。

という方式が無難なのではないかなと。

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

nginxの脆弱性が話題になってますが、APIサーバーを作る際にnginxのようなHTTPサーバーを前段に配置する必要がないのもGoの大きなメリットの一つですよね。

Goのメリットをざっとまとめると

・コンパイル後のバイナリサイズが非常に小さくなる(コンテナイメージも小さくなる)
・シングルバイナリでホストできる(コンテナイメージに含めるライブラリを最小限にできるので脆弱性リスクが軽減される)
・nginx等のHTTPサーバーやgunicornのようなアプリケーションサーバーが不要(構成が単純化されるので保守が楽＆脆弱性リスクも軽減される)
・学習コストが低い
・静的型付け言語である
・並列処理に強い
・エコシステムが確立されていて寿命も長そう

という感じになるかなと。

そしてこういった点を総合的かつ客観的に考慮すると、現時点でバックエンドのAPIサーバーの開発言語のファーストチョイスはGoになるというのが僕の見解です。

フロントエンドとバックエンドの言語を統一して初期の開発効率を高めることが重視される場合はTypeScriptという選択もあり得るとは思いますが、サービスが成長するとフロントエンドとバックエンドは分業体制になるのが一般的なので、長い目で見るとやはりGoが一番「無難」かなと。

https://t.co/4wPUnTec6Z

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

古着に関する知見が色々と溜まってきたので「メンズ向けの東京のおすすめ古着屋さん(主に非アメカジ系)」という記事を書いてみましたー😄

いわゆる一般的なアメカジ以外の古着にも興味ある方には結構面白い内容だと思うので読んでみてください♪

https://t.co/zpwgzXFJ20

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

技術力が非常に高いことで知られているエムスリーさんで不正アクセスによるデータ漏洩が発生したようですねー😳

エムスリーさんほどのテック系企業なら相当強固なセキュリティ対策が実施されていたはずなので、それでも突破されたというのはどういう侵入経路だったのか個人的にはかなり興味深いなと。

そしてそれはそれとして、こういった情報をPDFで出すのはあまりよろしくないですね。

この不正アクセスの影響を受ける方たちがパソコンで見るとは限らないので、どういう端末でも見やすいようにHTMLで公開するのが基本だと思いますが、PDFにしちゃってるあたりを見るとインシデント対応時のマニュアルや体制が意外と整備されてないのかなと。

サイバー攻撃を完全に防ぐことはできないですが、不正アクセスされたあとの対応に初歩的な不備があると世間からの信頼度がさらに低下してしまうので、今の時代はそこら辺もしっかりやっておかないとですよね。

https://t.co/793H9DEo18

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

ソースネクストさんのデータ流出事件、発表を見る限りどうやら「ユーザーのパスワードを平文で保存」していた可能性が極めて高そうですねー。

ソースネクストさんは自社製のセキュリティソフトとかも販売しているので、これは事業の信頼性に対する致命的な一撃になってしまうのではないかと。

セキュリティ系企業が脆弱性を放置して不正アクセスされてしまったことも問題ではありますが、「パスワードを平文で保存」は、見落としとかではなく完全な怠慢なわけなので。

初期仕様を引きずってしまったのだとしても、DBに保存されている既存の平文パスワードをハッシュ化する作業とバックエンドのコードの改修は工数をかけて順序を踏めば確実に対応できるものなので、その対応を怠ったというのはちょっと言い訳が効かないですよね。

最近のセキュリティ系ニュースの中で一番衝撃的でした笑

https://t.co/0LvRRJkFGQ

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

AWSのLambda Web Functionが話題になってますが、Lambdaという名前が付いてはいるもののこれはもうFaaSではなくPaaSですね。

なのでGoogle CloudのGAE Standard等が役割としては共通する部分が多いと思うのでユースケースに関してはそこから考えるのがよいのかなと。

GAE Standard等のPaaSは

・比較的シンプルなスタンドアロンのサービスを開発や保守の手間をできるだけ小さくしてホストしたい

・スパイクアクセスへの対応が必須

という場合に適しているというのが僕の認識ですが、規模の大きいWebサービスでは前者のニーズはあまり発生しないので、となると大規模AWS環境におけるユースケースとしては後者が本命ということになりそうな気はします。

ECS Fargateだとスパイクアクセスにはどうしても対応できない(スケールが遅すぎる)ので、スパイクが予測される時間帯に合わせて事前にタスク数を増やしてスパイクが終わったら元に戻すという非常に面倒な対応が必要になるのですが、Lambda Web Functionでそのペインを解消できるようならかなり魅力的ではあるかなと。

ただし現時点では「Private APIとしては使えない(常にPublic。PrivateLinkも使えない)」、「ランタイムはNode.jsのみ」という色々な制限があるので、大規模サービスでの実戦投入は他社さんでの実例を見てからというのが無難そうではあります。

https://t.co/53vCa3m7pd

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

最近の日本のITサービスに対する攻撃の手口として、Androidアプリのバイナリ解析によってバックエンドAPIの脆弱性を効率よく発見するという手法が増加しているみたいですねー。

まあバイナリ解析というのは特に目新しい手法ではないのですが、恐らくAIによってここの部分の作業が劇的に高速化されていて、攻撃者側からすると非常にコスパの高い攻撃手段になっているんだろうなと。

ちなみにこれに関して「だから無理してスマホアプリなんて作らずにWebでいいのに」的なことを言ってる人が散見されるようですがそれは完全に的外れですね😅

狙われてるのはバックエンドAPIの脆弱性であって、これはクライアントがスマホアプリであるかブラウザであるかは全く関係ないですから。

セキュリティ意識の低いチームだと、スマホアプリ用のAPIの認証とか認可とかその他のセキュリティ対策をおざなりにしがちなので、そういった穴を効率的に狙われてるんでしょうね。

とりあえず脆弱性診断は定期的にやった方がいいですし、開発フローの中にAI組み込んで脆弱性チェックを自動化するという「当たり前のこと」をちゃんとやっていかないとですよね。

https://t.co/l3ANHeOuEr

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

先日のヨーロッパ旅行の中でイングランドのリヴァプールとかも行ったんですよね。

その時の電車で乗り合わせた中にサッカーチームのリヴァプールのファンの人達と思われるおじさんの一団がいらっしゃったのですが。

電車の中からもう既にお酒のんで盛り上がっていて、多分若い頃からずっと同じメンツで毎週末来てるんだろうなと思うのですが、この文化は羨ましかったですねー。

試合中はもちろんみんなで熱狂して、勝っても負けてもその後パブ行ってビール飲んで色々なこと話してお互いに悪口言っていじりあってみたいな感じだと思うのですが、そういうのいいよなあと。

僕も何か熱狂的に応援できるスポーツチームとか推しを見つけたらもっと人生が豊かになるかもしれないなと思ったのでした笑

ちなみに試合は見れなかったですがアンフィールドはめっちゃかっこよかったです😊

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

半年くらい前は「MythosレベルのAIの登場でゼロデイ攻撃が激増する」的な予測をして世間を煽った個人やメディアが結構ありましたよね。

しかしあれから半年ほど経って各社の商用AIの性能がさらに向上し、未知の脆弱性発見能力がどんどん高まっているにも関わらず、ゼロデイ攻撃の激増は今のところ観測されていないというのが現状です。

その代わりに増えたのが「既知の脆弱性を悪用したと思われる攻撃とデータ漏洩」です。これはAIがかなり寄与していると考えてよさそうです。

この現象は考えてみると当然で、「AIを活用したゼロデイ脆弱性の発見とそれを活用した攻撃手法の考案と実行」というのは「不確実性が高い」つまり攻撃者にとって「コスパが悪い」わけです。

そんなことに工数や時間を使うよりも、既知の脆弱性が大量に放置されている「世界最悪のセキュリティレベル」の日本のITサービスを狙った方が換金しやすいですし、AIによって攻撃作業もかなり簡単になっているはずなので、そりゃ攻撃者もそっちを優先しますよね😅

なので企業の皆さんはゼロデイ脆弱性への対応をどうするかみたいなことを考えるよりも、ちゃんとエンジニアの指摘に耳を傾けて、自社サービスに大量に存在する初歩的な既知の脆弱性の解消にお金と時間を投下するという基本的なことからしっかりやった方がよいと思います。

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

最近ファッション方面ではStone IslandやC.P. Companyのヴィンテージアイテム探しを楽しんでおります😄

やはり「いいなあ」と思うアイテムは大体皆さん共通してるのでコレクター的な人たちとの先着競争になってしまうのですが、AIやテクノロジーを駆使して先んじたいなーと笑

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

一昨年から地道にコーヒー屋さん巡りをしているのですが、プアオーバーのシングルオリジンの浅煎りスペシャルティコーヒーが飲める東京のおすすめカフェについて記事にしてみました！

noteはAIで自動的に英語版も作ってくれるみたいなので、海外からの観光客の皆さんにも読んでもらえたらいいなと😊

https://t.co/Byz0YSftAL

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

先日のヨーロッパ旅行で見つけた、パリのメンズ向けの素敵な古着屋さんを5つほど紹介してみました！

Stone IslandやC.P. Company、その他ヨーロッパ系のデザイナーズブランドが好きな人には結構参考になるのではないかと思いますので、興味ある方是非読んでみてください😊

https://t.co/CGqHbsQHcO

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

NewsPicksさんでも不正アクセスによる情報漏洩が発生したようですが、最近本当にこれ系の攻撃が激増してますねー。

生成AIによって攻撃ツールが進化して既知の脆弱性の発見が効率化されているのは間違いなさそうですが、システムをセキュアに保つ仕組みの構築にお金と時間をかけない日本企業の体質が一番の原因ではあるかなと。

ちなみにNewsPicksさんの場合はサードパーティ性の管理ツールが不正アクセスされたことが原因だったとのことですが、多分そのツールに永続的な認証情報を渡しちゃっていたのではないでしょうか。

恐らくNewsPicksのエンジニアのどなたかはそういう問題点に気がついていたはずで、それを上の人にアラートしてるのだと思うのですけども、新規機能の追加タスクが優先されてセキュリティは後回しにされがちなんですよね。

Qilinというハッカー集団から「日本企業のセキュリティは世界最悪」とバカにされているようですけども、我々エンジニアではなく上の人達の意思決定のせいであることは是非ご理解いただきたいものですｗ😅

https://t.co/m8qveIxTiT

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

ここ数年ワインを勉強しているのですが、フランスのブルゴーニュのコート・ドールというエリアを自転車で巡った際のことをnote記事にしてみましたー😄

https://t.co/7lWazGhTWW

将来ブルゴーニュに行く人の参考になったらいいなと♪

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

渋谷駅の動線問題が話題になってますが、既に15年以上渋谷に住んでいて工事前後を実体験している僕の見解は

・東横線の地下化など不便になった部分もあるが埼京線のホーム位置や山手線が上下同じホームになったなど改善された部分も色々ある

・動線や乗り換え距離は結局は慣れの問題。東横線ホームとかは当初は遠くなって不便だなと思ったが毎日それを使うわけでないならいずれ気にしなくなるし初見殺しな動線も何回か使えば覚える。(それぞれの路線のホーム位置を体で理解できた後は余裕)

※ちなみに僕は山手線、半蔵門線、銀座線、東横線、井の頭線をかなりの頻度で使っていて、田園都市線、副都心線、湘南新宿ラインとかも時々使うのでほぼ全線割とまんべんなく使う人としての意見です。

という感じですかね。

なので例えば東横線を通勤で毎日使ってた人とかは工事前後で明らかに不便になったと思いますが埼京線の人は他の路線とホーム近くなって便利になったわけなので、全て悪くなったというのは「過度な一般化」つまり「認知の歪み」かなと。

あと例え乗り換えで歩くのが長くなったとしても「自動的にたくさん歩いて健康になれる仕組みが日常に組み込めてラッキー」とポジティブに考えればいいやんけと私は思うのですが笑😅

[yukaN-Twi-tter（人民） @yukankmr]

本当に今の渋谷駅は不便で不便で不便で不便で不便で不便で不便
ほんっっとうに最低の動線
前は2分で出られた駅の反対側が
歩いて歩いて登って降りてなんか店ん中通ってさらにまた降りて登ってほんでどこかわからなくなってから人に聞く

[勝又健太｜エンジニア系YouTuber｜雑食系エンジニア｜「Web系エンジニアになろう」著者 @poly_soft]

X上の言い争いを見ていて思うのですが、AIをやたら嫌う人って

「今まで自分の権威性で無茶な主張を通せていたのに生成AIが数十秒程度でエビデンスの有無などを調査してしまうので非常に都合が悪くて疎ましい」

という心情があるような気がするんですよねー。

若い人ほどAIへの許容性が高くて年配者ほどAIを嫌いがちなのはそういう事情(年配者になると何らかの権威を持つことが多いのでそれを使って物事を安易に解決しようとしがち)もあるのかなと。