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

バズったのでちょっと宣伝。 私は普段AWSを中心としたクラウドインフラのアーキテクチャ設計や構築の仕事をしています。 AWSを利用している企業さん向けに、クラウドアーキテクチャやクラウドセキュリティに関する技術相談、既存環境のレビュー、改善提案などもスポットでお引き受けしています。 SIerさんからの専門的な技術支援・レビュー業務のご依頼にも対応できます。必要に応じて改善の実作業まで対応可能です。 ご興味のある企業さんはお気軽にDMください😊 スキルセットと最近数年間の業務経歴書はこちらです。 github.com/kenta-polyglot/cv

カブアンドが色々と話題になっていますが、私の個人的な見解としては ・資産運用ではなく庶民の金融リテラシーを高めるための金融教育の一貫として個別株の取得をすすめることに一定の合理性はあるとしても、その教材として自社の複雑なスキームの未公開株を選ばせる合理性は乏しい。 ・庶民の金融リテラシーを高めたいならば「どんなに一生懸命勉強して金融リテラシーを高めたとしても長期的に市場平均に勝ち続けることは極めて難しい」「金融リテラシーが高い人ほど長期的に市場平均を上回る運用成績を残せているという信頼に足るデータは存在しない」という事実を先に伝えてからにすればいいのになぜそうしないのか疑問。 という感じですかね。 カブアンドに投資する人たちも ・「自分が仕組みを十分に理解できない金融商品には投資しない」が資産運用の大原則。 ・SPIVAのデータを見れば分かるように、一般庶民と比較して知力も情報分析力も経験値も非常に高いはずのアクティブファンドのファンドマネージャー達も長期的には大半が市場平均(インデックスファンド)に負けていく。 ・世界一の投資家のウーレン・バフェット氏でさえも、2022年までの20年間に関してはS&P500を上回れなかった。 という辺りはしっかり理解しておいた方がいいかなと。 (要するに金融に関してどんなに学んでも長期的に市場平均を上回るリターンを得ることは極めて難しいので、教養ではなくお金を増やすことが主目的なら勉強しても時間の無駄になるだけ。NISA等の非課税制度をフルに活用してインデックスファンドに粛々とつみたて続けるのがほぼほぼベストな選択) その上で「そういうことはどうでもよくて、とにかく前澤さんに課金したい。推し活がしたい」ということでカブアンドを使うのであればそれは好きにすればいいんじゃないかなと思います😊 note.com/poly_soft/n/n455983…

あとまあ公式発表によると「DevOpsエンジニアのノートPCからサービスコンテナにアクセスされた」とのことですが、アクセスされた(何らかの処理を実行された)ということは ・コンテナにシェルやユーティリティが含まれていた という可能性があるのかもなーと。(調査の利便性などを考慮してdistrolessなどを使っていなかったとか) AWSのECSならECS Exec、EKSならkubectl execとかでコンテナ内の任意の実行ファイルを実行できますし、「シェルがある」「書き込み可能なボリュームがある」「アウトバウンド通信が適切に制御されていない」といった条件が揃うとコンテナにログインして色々プログラムをインストールできてしまうので、そこから不正な出金処理を実行されてしまったとか。 まあ続報を待ちたいですが、金融系のようなセキュリティ要件の厳しいサービスだと、本番環境のコンテナは「distrolessなどを使う(余計な実行ファイルをコンテナに含めない)」「readonlyにする」「アウトバウンドを特定の宛先だけに制限する」などの対策が必須になるはずなので、そのいずれかをやっていなかったようなら随分守りが甘いなあと思うのでありました。

Binanceのハッキング被害すごい金額になってますが、強い権限を持つDevOpsエンジニアのノートPCが狙い撃ちにされたようなので、コインチェックさんの事件と同様に「ソーシャルエンジニアリングによる標的型攻撃」だった可能性が高いのかなと。 そして不正出金は短時間で集中的に実行されたようなので、少なくともシステムの構成に対して何らかの手段で事前に詳細な情報を得ていたっぽいですね。 Binanceほどの企業のサービスならば本番環境のインフラ上での妙な操作は(GuardDutyのような仕組みで)検知できるようにしていたはずですし、誰のPCを狙い撃ちにすればよいかは内部の人間に聞くのが一番確実なので、侵入してから色々調べたというよりはBinanceの現役もしくは元エンジニアが買収された可能性が高いんじゃないかなーと😅 いずれにしてもこれだけ巨額の暗号資産を扱うサービスにおいて、DevOpsエンジニアの端末から本番環境のインフラに強い権限を持ったユーザーでアクセスできてしまう方式は明らかにNGですよね。標的型攻撃だけでなくサプライチェーン攻撃のリスクもありますし。 運用効率が多少悪化したとしても、専用ルームに専用端末を用意して、本番環境に強い権限を持ったユーザーでアクセスできるのはその端末からのみに制限する等の堅固な方式にしとくべきだったのではないかなーと。

AWSのNetwork Firewallに、アウトバウンド通信の許可ドメインを一括で管理するための非常に有用なアップデートが入ったみたいですねー😄 ・アウトバウンド通信をVPCからの出口で一括で制限したい場合はNetwork Firewallが基本的には最適な選択肢。 ・ただしNetwork Firewallのドメインフィルタリング機能に関しては、SNIスプーフィングによって許可ドメインの制限を回避されてしまうという問題があった。 ・そのためAWS API用のアウトバウンド通信に対する許可はNetwork Firewallの従来のドメインフィルタリング機能だけでは安全に管理することはできなかった。(IPアドレスを直接指定して制限することは可能だが、AWS API用のドメインを名前解決して得られるIPアドレスのリストはAWS側の都合で変更される可能性があるので不適切) ・上記の理由によりAWS API用のアウトバウンド通信を制限する際には一般的にはVPCエンドポイントを使う方式を選択することになるが、AWS APIごとにエンドポイントが作られるためコストがかなり大きくなるという問題があった。 ・2026/10/21にリリースされたNetwork FirewallのRoute 53 Resolved IP Validationという機能により、Network Firewallだけでも(SNIスプーフィングで制限を回避されることなく)AWS APIのドメイン許可リストを管理できるようになった。(これによりAWS API用のVPCエンドポイントを廃止できるのでコスト面のメリットがかなり大きい) PCI DSS準拠のような厳しいセキュリティ要件を要求されていないWebサービスでも、アウトバウンド通信をデフォルトで拒否する構成が作りやすくなったのでかなりよいのではないかなと。(Network Firewall用のコストは相変わらず必要ではありますが) aws.amazon.com/jp/about-aws/…

一部で騒がれているCVE-2026-98432(Ubuntuのカーネル脆弱性)に関しては、AWSでFargate使ってる環境に関しては基本的に関係ないんですよね。 正確には「ホストカーネルの修正に関してはAWS側の責務なので我々にできることは何もない」ですが、既にAmazon Linuxでは対応済みになっているのでFargate基盤でも対応済みと考えてよいのかなと。(Health Dashboardに何らかの通知が来たりするはずですが緊急の場合だとどうなんでしょう) コンテナの方が常にVMより優れているというわけではないですが、この件のようにプラットフォーム側に責務を色々移譲できるのもコンテナのメリットであるということですね。 ubuntu.com/security/CVE-2026…

GitHub Actionsのlockfile機能がGAになり、依存先アクションのコミットSHAを明示的に指定しなくても、lockfileで固定できるようになったみたいですねー。 しかもworkflowファイルで指定されているアクションだけでなく、間接的に依存しているアクションも再帰的に固定できるようになったみたいなので、サプライチェーン攻撃への対策として早急に導入を検討する価値ありな機能なのではないかなと😊 github.blog/changelog/2026-1…

生成AIを学ぶスクールを全面的に否定するわけではないですが、高いお金を払う前に「生成AIの活用スキルは専門スキルにはなり得ない」という事実をしっかり認識しておいた方がよいと思うんですよね。 なぜならば ・生成AIの最新の活用ノウハウの大半は短時間でキャッチアップできてしまう。 ・数週間あるいは数ヶ月後には生成AIのバージョンアップにより現在の最新の活用ノウハウを(何も指示しなくても)生成AI自身が体現してくれる。 からでして。 OpenAIやAnthropicとかのAI企業は「AIの操作方法を人間が頑張って習得する必要性を減らし続ける競争」をしてくれているので、何もしなくても勝手に便利になっていくんですよね。 なので生成AIの習得に多額のお金を使ったり大きな時間を割くのは「すぐに陳腐化するスキルの習得に大きなコストをかけている」ということになり、とてもコスパが悪い(頭が悪い)ということになるわけです。 例えば一時期もてはやされた「プロンプトエンジニアリング」とかは今はもう誰も言及しなくなって、最近は「ループエンジニアリング」という手法が注目されるようになってますが、恐らく来年になるとこの手法もAIが自動的に対応してくれるようになって陳腐化するでしょうし。 もちろん「生成AIの勉強はしなくてよい」ということではなくしっかり活用できた方がいいですが、そのための勉強はそこそこで十分ですし、「他者との差別化に繋がるような参入障壁の高い他のスキルの習得」に時間を使うほうが、投下した労力が無駄になりにくいわけですね。 生成AIスクールが向いているのは「生成AIの学習程度でも自分一人ではどうしてもやる気が出ない」という人くらいかなーと😅

IDCFクラウドへの不正アクセスの件、 > オープンソースソフトウェアの脆弱性が悪用されたことにより発生 このOSSを「CloudStack」と勘違いしている人がいるみたいですが、それはIDCFクラウドの「仮想化基盤」用のOSSであって、「認証基盤」用のOSSではないですよ。 日経クロステックさんの別記事によると > この脆弱性の修正版は障害発生の数週間前に公開されていたが、修正版を適用する前に攻撃を受けたと回答した とのことなので、日本での使用事例の豊富さとか、該当しそうな脆弱性が発見された日付とかを考慮すると、認証基盤に使われていたOSSは恐らく「Keycloak」だったのではないかなと。 Keycloakは2026年8月にCVE-2026-18963の脆弱性(未認証の攻撃者がパスワードリセットフローの中でメールアドレスの確認処理を迂回して、管理者を含む任意のユーザーのパスワードをリセットできてしまうという脆弱性)が発見されていたようなので、これのパッチの適用が遅れたという可能性が高いのかなと。 いずれにしてもこういった致命的な脆弱性に対するパッチの適用が数週間も遅れるというのは相当に問題があるので、エンジニア観点からすると「これは仕方ない」と擁護するのはちょっと難しそうですね😅 idcf.jp/news/topics/20261027…

GMO熊谷さんの、身代金は払わない等の「毅然とした対応」は十分に評価できるのですが、ハッカーに対するここ数日間の「挑発的な発信」は非常によろしくないんですよね。 なぜならば「潜在的な攻撃者を無駄に刺激してしまう」からでありまして、注目を集めることや自分たちの力を誇示することを動機とする別のハッカー達からの新たな攻撃を誘発しかねないわけです。(不正アクセスだけでなくDDoS攻撃とか) GMOさんは「セキュリティーに強い企業」を全面に押し出してますが、どんなに自分の腕前に自信があったとしても、わざわざ喧嘩を売る必要はないんですよね。 セキュリティの専門家で「私が顧問をしているサービスのセキュリティは完璧です。攻撃できるもんならしてみてほしいですね」みたいなこと言う人いないですからね笑😅 GMOさんは過去からの経緯により一部の人達から相当嫌われているようですが、そういう人たちが将来的に攻撃者になる可能性もあるわけで、そこも含めてリスク管理していくのが「セキュリティ」なんですよね。 「トップの好感度が高い方が攻撃されにくい」と断言するわけではないですが、少なくとも僕が愉快犯的なハッカーだったら「今GMOを攻撃したら目立てるし、社長が嫌われてるから社会もむしろ自分を味方しそうだな」と考えちゃうかなーと笑

Anthropicの一部のチームではエンジニア採用におけるコーディング試験を廃止したみたいですねー。 AIエージェントの登場により実務におけるコーディングスキルの重要度が大きく低下したので、応募者の能力を測る指標としてはもはやコーディング試験は役に立たないという判断になったのかなと。 その代わりにどうやって応募者の能力を測るのかというと > 私自身はまだその答えにたどり着けていませんが、履歴書やポートフォリオを精査し、センスや共感力、そして原則に基づいた思考がうかがえる小さなプロトタイプを探しています。 とのことで、 ソフトスキル的な面や、システム設計に関する考え方とかをより重視する方針にされているっぽいですね。 日本における実務未経験者のエンジニア採用プロセスもAIエージェントの影響で大きく変化していると思いますが、少なくともポートフォリオに関しては ・データベース設計書 ・ネットワーク設計書 ・API仕様書 ・インフラ構成図 ・フロントエンドとバックエンドを完全分離(フロントはTypeScript、バックエンドはGoなど) ・インフラはTerraformでコード化 ・自動テスト ・CI/CDの導入 ・CIへの継続的な脆弱性チェックの導入(CRITICAL/HIGHの警告は全て潰す) ・その他、WAFの導入、CDNの導入、コンテナ化、ECSのオートスケールなど重要と思うことは全部。 といった辺りはもう全て最低限クリアしなければならないと考えてよいかなと。(どれも指示すればAIエージェントがそれなりに作ってくれちゃいますからね) その上で、下流部分ではなく上流の設計に関して「なぜその方式を選択したのか」「なぜその方式がベターだと考えたのか」を明確に合理的に説明できるかどうかを厳しく見られるようになっていくのではないかなと。 「実務経験が無いのに上流工程の思考が問われる」というのは中々の無理ゲーではありますが、AIエージェントにより下流工程が代替されてしまった以上、上流の設計面に関してその人なりに一生懸命調べて学習して作品に落としこんだということをアピールできないとモダンな自社開発企業さんには転職できないと思うので、頑張っていただきたいなと💪

すごい。自分で拡散していくスタイル笑😅

サイバー攻撃によるデータ漏洩がこれだけ発生しているのに、我々が最も心配しているFANZAはなぜ今のところ大丈夫なのかというと ・DMM従業員の皆さんの多くもFANZA会員のため「絶対にそれだけは避けたい」ということで最優先でFANZAの防御に工数を使ってくれている からではないかなーと笑😅