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

今回のPHP脆弱性問題で恐らく多くのエンジニアが認識したと思うのですが、 ・OSSのメンテナーの居住地は欧米が中心 ・そのため脆弱性パッチの公開時間は欧米のエンジニアが活動しやすい時間帯に設定されることが一般的 ・その時間帯は日本では夜遅くか深夜である。 ・AIの進歩により今後も即時の緊急対応が必要な脆弱性はかなりのペースで発見され続ける可能性が高い。 ・つまり今回と同様な「深夜の緊急の脆弱性対応」が日本において定常化してしまう可能性が非常に高くなっている。 という由々しき状況なんですよね。 この問題に関して、OSSの未知の脆弱性発見のペースをコントロールすることは不可能ですが、「エンジニアの深夜対応の負担をできるだけ減らす」ことは可能なわけです。 なので各企業さんはコンテナ化やテストの自動化やCI/CDパイプラインの整備やOSSの新しいバージョンへの早期の追随という「脆弱性発見時の対応作業をできるだけ楽にするための改修作業」にちゃんとお金と時間を投資しないといかんですよね。それはコントロール可能なわけですから。 それをやろうとしない企業さんからはエンジニアはどんどん離脱した方がいいですし、そういう企業さんがサイバー攻撃で消えてくれた方が日本全体のセキュリティレベルは向上するわけなので笑、睡眠時間を削ってまで守ってあげる必要はないかなあというのが私の見解です😅

「過去にGitHubでの情報漏洩が発生したのでGitHubは使用禁止。Self-ManagedのGitLabを使用せよ」というルールのご企業様の案件に参画したことがありまして。 (協力会社の人がGitHubの自分の公開リポジトリにソースコードをアップしちゃったのだとか) しかしこの類の問題はGitLabを自分たちでホストしても防止できませんし、むしろクラウドのマネージドサービスを使わないことで保守コストやセキュリティリスクが高まってしまうのですが、会社の偉い方たちにはそういった理屈は理解してもらえなかったようで。 そして結果として現在Self-ManagedのGitLabは即日の緊急対応が必要なレベルの脆弱性が連続して発見されているので、僕はもう案件離れているのですがこれ多分チームの皆さん対応面倒だろうなあと。 (コード化してある＆デプロイスクリプトも作ってあるのでバージョンを変更してコマンドを実行すればいいだけではあるのですがタイミングによっては深夜の緊急対応になってしまうので) クラウドサービスを使うのが絶対に正解というわけではないですが、セルフホストするとこういう緊急の脆弱性対応を毎回自分たちで頑張らないといけなくなるので、よほどの理由がない限りは「巨人の肩に乗る」のが無難だと思いますね😅 まあとにかく、技術の分からない人たちを技術的な決定に介入させてはいけません笑 itmedia.co.jp/news/article/2…

今回のPHPの脆弱性に対する復旧速度や対応コストは、そのサービスがどういう構成になっているかに大きく左右されるんですよね。 1. ECS Fargateなどのコンテナベースでサービスをホストしている＆PHPの新しいバージョンに追随し続けている＆CI/CDパイプラインも整備されていてテストもしっかり書いてある環境の場合： - PHPの脆弱性に対応したDockerイメージが公式から提供されれば迅速に対応できる。対象となるDockerfileのパッチバージョンを更新して変更をコミットするだけでよい。CIを実行してテストが通ればCDを実行して対応完了。早ければ30分以内で対応が完了する。 2. EC2などのVMベースでサービスをホストしている or PHPのバージョンが古すぎる or テストが書かれていない環境の場合： - コンテナと比べると更新の手数が多くなりがち(AMI等の更新まで自動化できているようなサービスは少ない)。PHPのバージョンが古すぎるとそもそもパッチが提供されないのでPHPのマイナーバージョンまたはメジャーバージョンを更新する必要があるがその際にWebフレームワークや依存パッケージその他が対応できていなかったりするとアプリケーションの大幅な改修も必要になる。テストが書かれていないと手動で各機能を動作確認することになるので復旧までさらに時間がかかる。 要するに1のようなモダンな構成 かつ 新しいバージョンへの追随を地道にやっていたサービスへの影響は小さい。 その逆に2のような構成のサービスだと復旧まで数日〜数週間以上必要になる可能性が普通にありますね。(そもそもサービスの再開を諦めるというケースも割と多発しそう) まあ新しいバージョンへの追随作業というのは後回しにされがちなのですが、一国の首相がSNSでアラートするような歴史に残るインシデントが発生したことで、会社の上の人達を説得しやすくなったのは良かったのではないかなと😅

ここ最近のサイバー攻撃の被害激増により改めてセキュリティエンジニアという職種が注目されていますが、セキュリティ分野「だけ」を専門にするかどうかはよく考えてみた方がいいとは思いますねー。 例えば小〜中規模ITベンチャーさんとかだと、セキュリティだけの作業は定常的な業務量がそこまで多くならないので、セキュリティエンジニアは単体の職種として成立しずらいんですよね。(バックエンドやインフラの担当者がセキュリティ業務を兼務するケースが大半であり通常はそれで十分) ある程度の規模の事業会社さんとかでも、セキュリティ周りの定常的な作業量はそこまで大きくならないので、情シスさんがベンダーの協力のもと他の業務をやりながらセキュリティ周りも兼務するという感じになるのが一般的なので、ここでも単体の職種になりづらいわけです。 なので必然的にセキュリティエンジニアはセキュリティ専業の企業さんで働くことが多くなるとは思いますが、それはつまりフロントエンドやバックエンドと比較して「活躍できる場所の選択肢がかなり限定される」ということになるわけで。 そして全体の求人数がそれほど多くならない＆働く先の企業が限定されがちということは「業務委託案件もかなり少ない」ということなので、フリーランス志向の方にはあまり向いていないということになりますし。(ここら辺はフリーランス案件サイトとかで確認するとすぐ分かると思います) なのでセキュリティ方面に関心のある若手の皆さんへのおすすめとしては ・まずはバックエンドやインフラを専門にしてそれらの職種で十分なキャリアを確立しつつ、そこにセキュリティ方面の知識や経験をプラスしていく ・十分キャリアが安定した後で、それでもどうしてもセキュリティ分野を単体で深く掘りたくなったらセキュリティ単体のエンジニアへのジョブチェンジを検討する。 という方式が無難なのではないかなと。

nginxの脆弱性が話題になってますが、APIサーバーを作る際にnginxのようなHTTPサーバーを前段に配置する必要がないのもGoの大きなメリットの一つですよね。 Goのメリットをざっとまとめると ・コンパイル後のバイナリサイズが非常に小さくなる(コンテナイメージも小さくなる) ・シングルバイナリでホストできる(コンテナイメージに含めるライブラリを最小限にできるので脆弱性リスクが軽減される) ・nginx等のHTTPサーバーやgunicornのようなアプリケーションサーバーが不要(構成が単純化されるので保守が楽＆脆弱性リスクも軽減される) ・学習コストが低い ・静的型付け言語である ・並列処理に強い ・エコシステムが確立されていて寿命も長そう という感じになるかなと。 そしてこういった点を総合的かつ客観的に考慮すると、現時点でバックエンドのAPIサーバーの開発言語のファーストチョイスはGoになるというのが僕の見解です。 フロントエンドとバックエンドの言語を統一して初期の開発効率を高めることが重視される場合はTypeScriptという選択もあり得るとは思いますが、サービスが成長するとフロントエンドとバックエンドは分業体制になるのが一般的なので、長い目で見るとやはりGoが一番「無難」かなと。 security-next.com/191645

古着に関する知見が色々と溜まってきたので「メンズ向けの東京のおすすめ古着屋さん(主に非アメカジ系)」という記事を書いてみましたー😄 いわゆる一般的なアメカジ以外の古着にも興味ある方には結構面白い内容だと思うので読んでみてください♪ note.com/poly_soft/n/n13d886…

技術力が非常に高いことで知られているエムスリーさんで不正アクセスによるデータ漏洩が発生したようですねー😳 エムスリーさんほどのテック系企業なら相当強固なセキュリティ対策が実施されていたはずなので、それでも突破されたというのはどういう侵入経路だったのか個人的にはかなり興味深いなと。 そしてそれはそれとして、こういった情報をPDFで出すのはあまりよろしくないですね。 この不正アクセスの影響を受ける方たちがパソコンで見るとは限らないので、どういう端末でも見やすいようにHTMLで公開するのが基本だと思いますが、PDFにしちゃってるあたりを見るとインシデント対応時のマニュアルや体制が意外と整備されてないのかなと。 サイバー攻撃を完全に防ぐことはできないですが、不正アクセスされたあとの対応に初歩的な不備があると世間からの信頼度がさらに低下してしまうので、今の時代はそこら辺もしっかりやっておかないとですよね。 corporate.m3.com/assets.ctfa…

ソースネクストさんのデータ流出事件、発表を見る限りどうやら「ユーザーのパスワードを平文で保存」していた可能性が極めて高そうですねー。 ソースネクストさんは自社製のセキュリティソフトとかも販売しているので、これは事業の信頼性に対する致命的な一撃になってしまうのではないかと。 セキュリティ系企業が脆弱性を放置して不正アクセスされてしまったことも問題ではありますが、「パスワードを平文で保存」は、見落としとかではなく完全な怠慢なわけなので。 初期仕様を引きずってしまったのだとしても、DBに保存されている既存の平文パスワードをハッシュ化する作業とバックエンドのコードの改修は工数をかけて順序を踏めば確実に対応できるものなので、その対応を怠ったというのはちょっと言い訳が効かないですよね。 最近のセキュリティ系ニュースの中で一番衝撃的でした笑 sourcenext.com/support/i/202…

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のみ」という色々な制限があるので、大規模サービスでの実戦投入は他社さんでの実例を見てからというのが無難そうではあります。 aws.amazon.com/jp/about-aws/…

最近の日本のITサービスに対する攻撃の手口として、Androidアプリのバイナリ解析によってバックエンドAPIの脆弱性を効率よく発見するという手法が増加しているみたいですねー。 まあバイナリ解析というのは特に目新しい手法ではないのですが、恐らくAIによってここの部分の作業が劇的に高速化されていて、攻撃者側からすると非常にコスパの高い攻撃手段になっているんだろうなと。 ちなみにこれに関して「だから無理してスマホアプリなんて作らずにWebでいいのに」的なことを言ってる人が散見されるようですがそれは完全に的外れですね😅 狙われてるのはバックエンドAPIの脆弱性であって、これはクライアントがスマホアプリであるかブラウザであるかは全く関係ないですから。 セキュリティ意識の低いチームだと、スマホアプリ用のAPIの認証とか認可とかその他のセキュリティ対策をおざなりにしがちなので、そういった穴を効率的に狙われてるんでしょうね。 とりあえず脆弱性診断は定期的にやった方がいいですし、開発フローの中にAI組み込んで脆弱性チェックを自動化するという「当たり前のこと」をちゃんとやっていかないとですよね。 nict.go.jp/press/2026/10/13-…

先日のヨーロッパ旅行の中でイングランドのリヴァプールとかも行ったんですよね。 その時の電車で乗り合わせた中にサッカーチームのリヴァプールのファンの人達と思われるおじさんの一団がいらっしゃったのですが。 電車の中からもう既にお酒のんで盛り上がっていて、多分若い頃からずっと同じメンツで毎週末来てるんだろうなと思うのですが、この文化は羨ましかったですねー。 試合中はもちろんみんなで熱狂して、勝っても負けてもその後パブ行ってビール飲んで色々なこと話してお互いに悪口言っていじりあってみたいな感じだと思うのですが、そういうのいいよなあと。 僕も何か熱狂的に応援できるスポーツチームとか推しを見つけたらもっと人生が豊かになるかもしれないなと思ったのでした笑 ちなみに試合は見れなかったですがアンフィールドはめっちゃかっこよかったです😊

半年くらい前は「MythosレベルのAIの登場でゼロデイ攻撃が激増する」的な予測をして世間を煽った個人やメディアが結構ありましたよね。 しかしあれから半年ほど経って各社の商用AIの性能がさらに向上し、未知の脆弱性発見能力がどんどん高まっているにも関わらず、ゼロデイ攻撃の激増は今のところ観測されていないというのが現状です。 その代わりに増えたのが「既知の脆弱性を悪用したと思われる攻撃とデータ漏洩」です。これはAIがかなり寄与していると考えてよさそうです。 この現象は考えてみると当然で、「AIを活用したゼロデイ脆弱性の発見とそれを活用した攻撃手法の考案と実行」というのは「不確実性が高い」つまり攻撃者にとって「コスパが悪い」わけです。 そんなことに工数や時間を使うよりも、既知の脆弱性が大量に放置されている「世界最悪のセキュリティレベル」の日本のITサービスを狙った方が換金しやすいですし、AIによって攻撃作業もかなり簡単になっているはずなので、そりゃ攻撃者もそっちを優先しますよね😅 なので企業の皆さんはゼロデイ脆弱性への対応をどうするかみたいなことを考えるよりも、ちゃんとエンジニアの指摘に耳を傾けて、自社サービスに大量に存在する初歩的な既知の脆弱性の解消にお金と時間を投下するという基本的なことからしっかりやった方がよいと思います。

最近ファッション方面ではStone IslandやC.P. Companyのヴィンテージアイテム探しを楽しんでおります😄 やはり「いいなあ」と思うアイテムは大体皆さん共通してるのでコレクター的な人たちとの先着競争になってしまうのですが、AIやテクノロジーを駆使して先んじたいなーと笑

一昨年から地道にコーヒー屋さん巡りをしているのですが、プアオーバーのシングルオリジンの浅煎りスペシャルティコーヒーが飲める東京のおすすめカフェについて記事にしてみました！ noteはAIで自動的に英語版も作ってくれるみたいなので、海外からの観光客の皆さんにも読んでもらえたらいいなと😊 note.com/poly_soft/n/n641b6e…