「システムの起動そのものが不可能で、データ復旧の手段はない」――製粉大手のニップン（東証一部上場）は8月16日、7月7日に受けたサイバー攻撃の詳細と影響を明らかにした。
日本の製粉大手に「前例ない」大規模攻撃 大量データ暗号化 起動不能、バックアップもダメで「復旧困難」 - ITmedia NEWS
グループ会社を含むサーバの大半が同時攻撃を受け、バックアップを含む大量のデータが暗号化されて復旧不能に。外部専門家に「前例のない規模」と報告を受けたという。
日本の製粉大手に「前例ない」大規模攻撃 大量データ暗号化 起動不能、バックアップもダメで「復旧困難」 - ITmedia NEWS
財務システムも被害を受け、早期の復旧が困難なため、8月5日に発表予定だった2021年4～6月期の決算は、約3カ月延期。8月16日が提出期限だった四半期報告書の提出も、11月15日に延期する。
日本の製粉大手に「前例ない」大規模攻撃 大量データ暗号化 起動不能、バックアップもダメで「復旧困難」 - ITmedia NEWS
外部専門家に調査を依頼したところ、（1）被害を受けたシステムすべてで、サーバのボリュームまたはサーバの内部に格納されたファイルの大部分が暗号化され、システムの起動そのものが不可能、（2）サーバの早期復旧に有効な技術的手段が確認できない、（3）データのバックアップを管理しているサーバも同じ状況であり、データの復旧の有効的な手段が「ない」と報告を受けたという。
日本の製粉大手に「前例ない」大規模攻撃 大量データ暗号化 起動不能、バックアップもダメで「復旧困難」 - ITmedia NEWS
⇧ まじか...
気になるのは、システムに脆弱性とかあったのかってところよね。
「DX（Digital Transformation）」 に耐えうるシステムの構成になってないレガシーなシステムで改修とかにコストがかかるものについては塩漬けにすれば良い、って話を聞くけども、システムに対する攻撃のニュースを目にするとセキュリティー的に大丈夫なんかな？って気持ちになりますな。
「塩漬け」の話は、
⇧ 上記のページの「デジタルトランスフォーメーションに向けた研究会」の「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～（本文）」のPDFで紹介されてましたな。
⇧ ってな感じの指針っぽいんだけど、もし脆弱性とか出てきたら、「塩漬け」するってわけにはいかないとは思うけど、その時になってレガシーなシステムに対応できる人材がいない場合はどうするんだろうね？
まぁ、もしも攻撃を受けて大損失を被ったとしても、やむを得ないってことなんかな、優先順位が分からんから、何とも言えんけども。
契約プログラミングって何ぞ？
Twitterで、
Javaでコード書いてるけど割とこれ https://t.co/8KU99RqIgM
— なぎせ ゆうき (@nagise) 2021年8月17日
契約プログラミングの契約を定める
— なぎせ ゆうき (@nagise) 2021年8月17日
⇧ Javaの有識者の方が取り上げてたツイートで、「契約プログラミング」なる言葉が出てきたので、Wikipediaさんに聞いてみた。
契約プログラミング（けいやくプログラミング、Programming By Contract）または契約による設計（けいやくによるせっけい、Design By Contract）とは、プログラムコードの中にプログラムが満たすべき仕様についての記述を盛り込む事で設計の安全性を高める技法。プログラミング言語Eiffelで初めて導入された。"Design by Contract" の頭文字からとった DbC (ディービーシー) でよばれることが多い。
⇧ な～るほど、ザ・ワールド。
「インプット」と「アウトプット」 を先に作るってのは、確かに、複数人で分担して開発してる時なんかは、分かりみが深い気がしますかね。
特に他システムと連携せざるを得ないような機能を実装してる場合は、ある程度、どんな項目が必要かっていうのが出揃ってから、コーディングに取り組んでいかないと出戻りの嵐にもなりますし、ある程度の見通しが立ってから詳細な実装への流れに持っていくのは、意識していきたいですね。
プログラミングパラダイム（programming paradigm）とは？
Wikipediaさんに聞いてみた。
⇧ 出た～、「模範」と言えば、優等生が言われがちな言葉～。
具体的には、
プログラミングパラダイムは、プログラマにプログラムの見方を与えるものと言える。たとえば、オブジェクト指向プログラミングにおいて、プログラムとはオブジェクトをつくりそれを管理するものである。関数型言語においては、状態を持たない関数の評価の連続である。
プログラミング言語が異なれば、対応できるパラダイムも異なってくる。SmalltalkやJavaは手続き型やオブジェクト指向、Haskellは関数プログラミング、といったように、比較的少数のパラダイムに対応している。一方で、竹内らのTAOのように多数のパラダイムに対応した言語（マルチパラダイムプログラミング言語）も存在する。
⇧ ってな感じで、プログラミング言語によって「模範」ってものが異なるんですと。
まさに「郷に入れば郷に従え」じゃないけど、選択する「プログラミング言語」によっては「設計」側が影響を受けざるを得ないってこともありそうですかね。
というのも、
多くのプログラミングパラダイムでは、「やってはいけないこと」（禁じ手）が存在する。たとえば純粋な関数型プログラミングでは、副作用があってはならず、構造化プログラミングではgotoの無制限な利用は戒められる。
⇧ プログラミング言語によって、「禁じ手」があるんだそうな。
「設計」してはみたものの、その仕様を実現するには「禁じ手」を使わざるを得ない、みたいな展開になってしまうこともあり得ないとは言い切れないけども、そもそも選択したプログラミング言語だと実装できないような仕様となった場合、
- 設計を変更する
- プログラミング言語を変更する
のどっちかを選択することを迫られるってケースも無きにしも非ず、ということが起こるかもって考えると、 「鶏が先か、卵が先か」ってなパラドックスじゃないけど、「設計が先か、実装が先か」って悩ましく思う時もあるんかな？
脱線しましたが、「契約プログラミング」ってのは「プログラミングパラダイム（programming paradigm）」の例の1つってことらしい。
まぁ、覚えることが多過ぎて毎日キャパシティオーバーにさらされることで、ストレスしか感じない...
世は大ストレス化社会ってことですかね。
貧弱なキャパシティを増やせというツッコミが飛んできそうですが...
今回はこのへんで。
