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

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

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

最近こっち方面の情報に疎くなっていたので全く知らなかったのですが、「エンジニアのミカタ」というSES系企業さん、経歴書の魔改造で大炎上していたみたいですねー😅 以前から ・実務未経験者に門戸を開いているSES系企業さんには気を付けよう ・実務未経験者がSES系企業経由で本当の意味での「開発の実務経験」を積める可能性はゼロに近い(生成AIが普及した現在はさらにその傾向が強い) ・開発と全く関係ない仕事(例えば家電量販店での販売の仕事など)をアサインされたりするケースも非常に多い ということはずっと伝えてきましたし本にも書きましたが、まだやっぱり引っかかっちゃう人いるんだなと。 はっきり言いますが、実務未経験者に門戸を開いているSES系企業さんはほぼ100%「実務未経者をカモにして搾取しようとしているだけ」と考えて差し支え得ないですよ。 社内でのIT研修とかを売りにしているSES系企業さんもあるようですが、下流工程のコーディング作業をほぼAIが担当できるようになった現在、そういった研修程度で身につけた知識なんて何の役にも立たないですしね😅

ハッカー集団による個人情報晒しが始まってしまったようですが、本当に攻撃で流出したものかどうかはまだ不明なものの、 ・熊谷さんのプライベートジェット利用費のごく一部でもデスクトップクラウドのセキュリティ対策に使われていればこの事件は防止できた というのは間違いないですねｗ😅

ペンタゴンの不正アクセスの一件に関しては下記の記事とかを読んでみると認識が変わると思いますよ。 > 国防人材データセンター(DMDC)で発生した情報漏洩は、高度なサイバー攻撃によるものではなかった。これは、連邦政府全体のサイバーセキュリティ基準の策定を支援する組織において、暗号化、アクセス管理、監視といった基本的なセキュリティ対策が機能しなかったことが原因である。 要するに「高度で防御が難しいサイバー攻撃を受けたわけでなく、基本的なセキュリティ対策に初歩的な漏れがあった」ことが不正アクセスの原因だった可能性が高いわけです。 現在の日本におけるサイバー攻撃の被害も要因はほぼこれです。基本的なセキュリティ対策に継続的にしっかりお金と工数を使っていれば大半のインシデントは発生しなかったということですね。 techtarget.com/cybersecurity…

AIの進化によるサイバー攻撃の激増で「インターネットが壊れかけている」みたいな恐怖や絶望に襲われている人もいらっしゃるようですが、エンジニア観点だと全然違うんですよね。 いま壊れているのは基本的に「セキュリティ周りに十分な投資をしてこなかった企業さんのサービス」でありまして、優秀なエンジニアにしっかりお金を払ってモダンな構成を維持して脆弱性対策をしてきた企業さんのサービスは大きな被害は受けていないわけです。 「KADOKAWAやGMOもやられているじゃないか」という意見もあるかと思いますが、それらの企業さんは「優秀なエンジニアは一定数在籍しているもののセキュリティ対応を先送りにし続けてきた」ツケを今払わされている企業さんなんですよね。 なのでモダンな環境で働いているエンジニアからすると 「目立ちたがりで外見を飾ることばかりにお金を使ってきたお城が次々と攻め落とされているが、守り固めにしっかり投資してきた自分たちの城はほぼ盤石なので、他の城が陥落していくことに関しては"自業自得"としか思っていない」 という感じなんですよね。 そしてサイバー攻撃が増えれば増えるほど、セキュリティ周りの知見に強みを持つタイプのエンジニアの需要は高まるので、恐怖よりも「人材価値が勝手に高くなりそうだから嬉しいな」と思ってるエンジニアの方が多いと思います笑😁

AWSのペネトレーションテスト用サービスであるAWS Continuum for penetration testingの解説、非常に参考になりました😊 先日のアップデートでCIにも組み込めるようになり、さらに「前回デプロイ時との差分だけをペンテストする」という機能もあるみたいですね。(CI/CD統合はまだプレビュー段階ではありますが) 大抵のWebサービスはCI時の静的解析ツールによる脆弱性チェックだけでもそこそこ大丈夫だとは思いますが、セキュリティ要件の厳しいプロジェクトだとCI時の差分ペンテスト実行も今後は要求されるようになっていくのかなと。 私の予想としては ・AWSのベストプラクティス等に沿って開発されている＆既にCIにSASTが導入されているモダンなWebサービスは攻撃面がある程度限定されるので、AWS ContinuumのようなAIエージェントによるペンテストで十分な場合が多そう。 ・AWS Continuumはそこそこ高額ではあるものの、外部のセキュリティ専業会社にペンテストを依頼するのと比べると遥かに低価格。 ・AWS ContinuumがCI/CDに組み込めるということも考慮すると、十分な技術力を持つ自社開発系企業におけるペンテストは今後は外部に委託せず自社チームのみで完結させる方向になっていく可能性が高い。 ・外部のセキュリティ企業が「我々の脆弱性チェックサービスの方が優れている」と主張したいのであれば、AWS Continuum等のAIベースのペンテストツールと自社の熟練ペンテスト担当者を競わせて、脆弱性発見率において明確に自社の方が優れているということを証明する必要が出てくるのでは。 という感じになりますかね。 speakerdeck.com/asanoharuki/…

ブログ拝見しましたが、エンジニア観点からすると > サービスの可⽤性への影響や他の対処事項との優先順位を考慮しながら慎重に対応を進めた結果 この箇所に関してはかなり疑念を抱いてしまいますね。 今回の一件における最大の問題は、(ハッカー集団の公表している情報が正しいのであれば) ・管理者が顧客のVPSにリモートログインする際にノーマルなRDPで接続してしまうと管理者の認証情報を窃取・悪用される可能性があるにも関わらず、その方式を使い続けていた。 という点にあると思うんですよね。 私が調べてみた限り、RDP接続の際にRestricted Admin Modeを設定すれば認証情報の窃取は容易に防げたはずなので、なぜそんな簡単な設定をやらなかったのか、エンジニアとしてはそこが非常に不思議だなと思うわけです。 Restricted Admin Mode方式に変更することで保守作業の効率がやや悪化する等の問題はあるかもしれませんが、顧客VPSの可用性に影響を与えるようなものではないはずなんですよね。(接続時の方式を変更するだけなので顧客VPSの再起動は不要) しかも優先順位的に考えたら「最優先」でやるべきことなので、どういう意思決定によりその対応を後回しにして脆弱性を放置することになったのか、もしくは気が付かなかったのか、そこが知りたいなと。 私の現時点の推測ですが、GMOさんの保守作業において、顧客VPSにRDP接続した後にActive Directory内の保守資材等が置いてあるサーバー等に管理者権限でアクセスしなければならないような手順が一部存在したのかなと。(もしくは各VPS内に配置している保守スクリプト等がそれを前提に書かれていたのかなと) つまり「ダブルホップ」しないと実施できない保守作業があったのかもしれませんが、メリデメを考慮するとどう考えてもここは利便性を優先したら駄目なんですよね。(認証情報を窃取された場合の被害が甚大すぎる) ここら辺の意思決定に関して「なるほどそれは仕方ないかもなあ」と思えるかどうかは、保守作業で通常のRDP接続が必要だった理由を公表してもらえればエンジニアは判断できるので、是非それはやった方がよいのではないかなと。(サービスは完全に作り直すとのことなので技術情報を公開しても何も問題はないはず) 現時点ではGMOさん側からの技術周りの情報がなく、ハッカー集団が公表している内容だけから推測せざるを得ないわけですが、それだと ・ある程度の工数を使えば通常のRDP接続を使わない方式に変更できたのにセキュリティ的な重要性を見誤った or そもそも脆弱性に気が付かなくてそれをしなかった。 ・つまりどちらにしてもGMOさんのセキュリティに関する知見はそれほど高くない。 という判断になっちゃいますので😅 個人的には「そもそも通常のRDP接続時の脆弱性を知らなかった」に一票ｗ

これはGMOさんを攻撃した(と自称している)ハッカー集団からの声明ですが、この内容が本当だとすると、お名前ドットコムデスクトップクラウドには「初歩的 かつ 非常に大きな」脆弱性が存在していたみたいですね。 僕は現在はLinux系が専門なので知りませんでしたが、 ・WindowsのRDPでは、管理者がリモートログインした際に接続先の端末に認証情報が残り、その端末の管理者権限を持つユーザーに窃取・悪用される可能性がある ようですね。(とんでもない仕様なのでこれはまずMicrosoftが悪いw) そのため、RDPによる信頼度の低い端末への接続においては、Restricted Admin Modeなどを設定して認証情報を保護する必要があるのだそうです。 この保護はActive DirectoryのGPOとかで割と簡単に設定できるようで、そしてこのRDPの脆弱性に関しては割と広く知られている初歩的なものみたいですね。 ところが、GMOさんの管理チームは何らかの理由でこの設定やっていなかったか、もしくは単に失念してしまったのかなと。 この設定漏れにより、保守担当者がRDPでユーザーのVPSに接続した際に管理者アカウントの認証情報が漏洩し、VPS内で管理者権限を持つ攻撃者がその認証情報を取得してActive Directory全体の管理者に昇格し、他の顧客のVPSにマルウェアをばら撒いた、という展開のようですね。 そしてもう一点「ドライブリダイレクション」という記述がありますが、この機能が有効になっていると、RDPのリモート側からローカル端末のファイルを読み書きできてしまうのだそうです。(これもとんでもない仕様ですがｗ) なのでこの機能を悪用するとユーザーのVPSからローカル端末に対してマルウェアを配置することが可能になるわけですが、ハッカー集団の情報が事実ならば、お名前ドットコムデスクトップクラウドさんでは2019年からずっとこの機能が有効化されていたようです。 これも何か理由があってそうしたのかもしれませんが、事実だとしたらなんでそんな恐ろしい機能をONにしていたのかなと😅 これらを考慮すると、先ほどGMOさんが発表した第4報の 「民間事業者単独の防御・事後対応のみでは、国境を越えて暗躍する高度なサイバー犯罪集団による国民資産の略奪を根絶することは困難です。」 の部分に関してはちょっと同意しかねる部分が出てきますね。 個人的な見解としては 「あなた方のサービス、WindowsのRDPを使ってサービスを管理するなら誰でも当然のように知っておくべき初歩的な脆弱性を、長期に渡って放置していてそこを攻撃されただけですよね？」 という感想になってしまいます笑😅 まあハッカー集団が本当のことを言ってると確定したわけではないですが、サービスは全く新規に作り直すとのことなので、他の企業さんの今後の参考のためにもGMOさん側からも詳細な攻撃情報を出してほしいとこですね。 普段Windows使わないので色々と学びになりました。やっぱりLinuxがいいですね笑

ちなみに攻撃はまだ終わっていない可能性がありまして、ハッカー集団の言っていることが事実ならば、今度は各ユーザーのローカル端末の色々な機密情報やプライベート情報が人質になっているようですね。 これも当然身代金要求をGMOさんは拒否するでしょうし(当然そうすべき)、そうなると数万人レベルでの機密情報(電話番号や住所とかとは比較にならないレベルの超重要情報や絶対に人に見られたくない性癖の情報など)がネットに流出する可能性があるわけで、なかなか前代未聞の事態になってきたなあと。 他人事ではないので、お金関係はもちろんですが、我々も自分の端末内の絶対に人に見られたくないものは早めに整理した方が良さげですね💦

ざっと読んでみましたが、現時点でやれる対応としてはほぼほぼベストなのではないかなと。 初動が遅すぎた感はありますが、「既存のサービスの改修ではなく新サービスを開発して移行」「ユーザーの損失の全額補填(条件はあるみたいですが)」とかは非常によいと思いますね。 (前者は恐らくエンジニアからの強い提案もあったのかなと思いますが。多分アーキテクチャやセキュリティ的に以前から色々と問題が指摘されていたのかなと) そして「脅迫があった」ことを認めた上で「身代金は払わない」とキッパリ宣言したのもよいと思います。 ここら辺はKADOKAWAさんとは大きく違いますね笑 身代金払っちゃう企業があるからサイバー攻撃がどんどん激化してしまうわけなので、GMOさんみたいな大企業が明確に拒否するのは社会にとって大切かなと。 まあとは言うものの、FXという「ギャンブル」をさらに自動取引で実行するという相当にリスキーな行為を助長するようなサービスを維持することが、本当に社会にとって必要なのかどうかは微妙なとこではありますが笑😅

GMOの「お名前.com デスクトップクラウド」へのハッキングの件、まだ全貌は分かっていませんが「攻撃者からGMOグループに対する脅迫が実際にあった可能性」は割と高そうな気はしますね。 個々のユーザーのFX口座に侵入できたとしても、攻撃者がそれによって直接的な金銭的利益を得るのは難しい＆コスパが悪いので、「ユーザーの資産を溶かされたくなかったら身代金を払え」とGMO側を脅迫する方が合理的なんですよね。 もちろん実際に脅迫があったとしても企業側にはそれを公表する義務はないのですが、不正アクセスされていることをユーザーおよび世の中に対してもっと迅速に公開していたら被害規模を小さくできた可能性はあったわけで。 こちらの朝日の記事の信憑性に関しては何とも言えませんが、これを見る限りユーザーのFX口座への攻撃は21日夕方には発生していたのに対して、GMOからの発表があったのは22日の17時。 この発表が遅すぎたのではないかという点は今後かなり厳しく突っ込まれるのではないでしょうか。 いずれにしてもこの一件と先日のinfoQの不正アクセスの件を併せて「セキュリティに強い企業」としてのGMOさんの評価はかなり毀損されてしまったかなと。 GMOさんの中に非常にレベルの高いセキュリティエンジニアが在籍されていることは間違いないですが、「凄いエンジニアがいる」ことと「その人たちのスキルや経験を実際のサービスに反映する」ことはまた別でありまして、GMOさんは後者があまりうまくいっていないみたいですね😅 asahi.com/articles/ASVBQ436F…

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

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