仏ベルサイユで開かれた計量単位などを決める国際会議「国際度量衡総会」は15日（現地時間）、時刻調整に使う「うるう秒」を2027年5月20日に廃止する決議を採択した。高度情報化社会でシステムの障害を防ぐため、半世紀以上続いた仕組みを見直す。
時刻の国際基準「協定世界時」は原子時計を基にしている。高精度なものは数億年で1秒程度しかずれない。一方、地球が自転に要する時間はわずかに変動するため、原子時計に基づく時刻との差が0.9秒を超えないよう、数年ごとの6月末か12月末に1秒を加えて調整してきた。
うるう秒は1972年の導入以来、27回実施してきたが、同じ時刻の重複でコンピュータが誤作動を起こしたり、システムが停止したりする恐れがある。12年には国内のインターネット接続事業者でサーバ障害が発生し、豪州でも航空機の搭乗手続きに支障が生じ、多数の便が遅延。さらに今後、1秒を削る「負のうるう秒」が必要となる可能性もある。
決議では、協定世界時と自転に基づく時刻のずれの許容範囲を0.9秒から1時間に広げる。これにより、数世紀は調整が不要になる見通しで、通信や金融取引などの安定化につながる。22年の前回総会では、35年までに廃止する方針を決めていた。
⇧ とりあえず、「ソフトウェア開発」に携わる「エンジニア」として気を付けねばならないことがあるのであれば、共有して欲しいところなのだが...
例えば、「既存」の「システム」において、「うるう秒」に対する特別対応などしている場合に、「うるう秒」廃止の影響があるのか、特段、何の対応も必要ないのかなど。
セキュリティ領域を意識したログ設計、または、ログの種類など
昨今、
- 不正アクセス
- 情報漏洩
が「ニュース」として取り上げられることが多くなって来ている印象があるのだが、過去にも「メディア」で取り沙汰されていなかった「セキュリティ」に関する「犯罪」は多発していそうな気はする...
で、
旅行予約サイト「skyticket」の不正アクセスで、運営元のアドベンチャー（東京都渋谷区）は10月16日、最大6140人のクレジットカード情報が流出したと発表した。9日の初報では「カード情報の流出はない」としていたが、その後の調査で流出を確認し、訂正した。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
対象は、2017年2月から18年6月までの間に、有料会員サービス「skyticket プレミアム」料金支払いのためにカードを登録・利用した顧客で、カード番号、カード名義人名、有効期限（一部の顧客はカード番号のみ）が含まれていた。セキュリティコードは含まない。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
同社は2018年6月までカード情報を自社サーバに保管していた。その後、決済代行会社での管理に移行したが、移行時に「skyticket プレミアム」の会費支払いの変更履歴（ログ）が削除されないままサーバに残っており、これにカード情報が含まれていた。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
これ以外にも、18年6月以前の支払いに関するカード情報がサーバに残っていないかは確認を進めている。18年7月以降のカード情報は流出していない。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
カード情報を含むログが取得されたのは、26年10月3日。判明したのは10月15日だったという。データは暗号化していたが、暗号化に用いる情報も不正に取得されたため、読み取られるおそれがあるという。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
また新たに、会員特典の「ベネフィット・ステーション」（ベネフィット・ワンが提供する福利厚生サービス）を利用するための会員ID、氏名、パスワードも流出したことがわかった。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
このデータも暗号化していたが、暗号化に用いる情報も不正に取得された。
「skyticket」クレカ情報も流出、カード番号など最大6140人分 「流出なし」の初報を訂正 - ITmedia NEWS
⇧ 上記サイト様で「不正アクセス」により、
- 犯罪者
- 犯罪組織
などの「サーバー」への「侵入」が行われてしまい、諸々の「情報漏洩」が発生したとありますと。
で、言い方は悪くなってしまうかもなのだが、公開されている「情報」を「他山の石（たざんのいし）」や「殷鑑遠からず（いんかんとおからず）」として、そもそも、「システム」に対する「不正アクセス」についての「監視運用」の体制はどうなっているべきなのだろうか？
と言うのも、
エンタープライズアーキテクチャ（英: enterprise architecture、略称:EA) とは、組織全体の目的を達成するために、ビジネス戦略とITシステムを全体最適の視点から統合的に設計・管理するためのガイド、およびその実践手法である。
EAは、組織のビジネス目標、業務プロセス、データ資産、アプリケーション、および基盤技術の現状（As-Is）を可視化し、目指すべき将来像（To-Be）を定義する。その上で、現状から将来像へ向かうための移行計画や、設計のガイドラインを提供する。これにより、組織は複雑化するビジネス環境や技術の進化に対して、一貫性を持って適応することが可能になる。
現代のデジタルトランスフォーメーション（DX）の文脈においては、単なるITの統制を超えて、以下の点が特に重視されている。
- 戦略とITの整合性: 経営戦略に基づいてIT投資の優先順位を決定し、部署ごとの場当たり的なシステム構築によるサイロ化を防ぐ。
- 変化へのアジリティ: 組織構造やIT基盤を疎結合（組み替えやすい状態）に保ち、市場環境の変化や新技術の導入に迅速に対応する。
- 段階的な移行計画の策定: TOGAFなどの代表的なフレームワークが示すように、現状から理想の将来像への道筋を、実行可能な移行アーキテクチャとして描き、安全かつ確実な変革を支援する。
⇧ 上記にありますように、
- 現状（AS IS）
- あるべき姿（TO BE）
の「乖離（Gap）」が「問題」であり、「問題解決」することで「乖離（Gap）」を解消していけるわけで、そもそもの「ゴール」である「あるべき姿（TO BE）」が分かっていないと「戦略」の立てようが無い...
ネットの情報を漁っていたところ、
セキュリティ業務において、ログは多くの役割を果たすようになってきました。分類方法はさまざまですが、ここではNIST（米国国立標準技術研究所）が公開している、重要インフラのためのサイバーセキュリティフレームワークをベースに、「1.検知目的」と「2.分析目的」の2つの観点でログを用いた業務を大きく分類しています。
セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ） - ＠IT
- 検知目的
外部からの攻撃がシステム内に侵入してきていないかをいち早く検知するため - 分析目的
インシデント対応時に「どれだけの情報を持ち出されてしまったのか」「どの経路で、いつ、どこから、どのような方法で侵入されたのか」を追跡するため
セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ） - ＠IT
⇧ 上記サイト様にありますように、「The NIST Cybersecurity Framework (CSF) 2.0」の考え方を導入している場合、
- 検知（DETECT）
- 侵入されていないことが明らかになったケース
- 侵入されたことが明らかになったケース
- 対応（RESPOND）
- 侵入されていないことが明らかになったケース
- 侵入されたことが明らかになったケース
といった感じで、「切り分け」をするにあたっても何某かの「ログ」は必要になって来るはずである。
実際の「切り分け」を進めるにあたっては、
- 検知（DETECT）
- 監視
- 通知
- 対応（RESPOND）
- 分析
⇧ 上記のような「フロー」が実現できる「仕組み」が導入されている必要があると。
ちなみに、「The NIST Cybersecurity Framework (CSF) 2.0」については、
⇧「独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Innovation Platform Agency, Japan、略称: IPA）」が「情報」を公開してくれているが、昨今、「フロンティア AI」などが悪用されていくことが予想されるので、「AI」を考慮した「NIST IR 8596（Cybersecurity Framework Profile for Artificial Intelligence, or Cyber AI Profile）」の作成が「アメリカ」の「米国国立標準技術研究所（NIST：National Institute of Standards and Technology）」によって進められているらしい。
「セキュリティ」領域における「ログ」については、
セキュリティ業務において利用するログの種類
次に、セキュリティ業務で利用するログにはどのようなものがあるかを見ていきます。セキュリティ対策は多層防御の概念に基づき、外部脅威から保護するために対策を講じるようになりました。つまり、多層化されたことで、多くの種類のセキュリティ製品が企業内の保護対象システムを囲い、脅威から隔離されるようになったのです。
セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ） - ＠IT
そのため、さまざまなベンダーの提供するセキュリティ機器や、保護対象システムのサーバ内にあるソフトウェアからログを取得し、単体のログでは見つけることが難しい外部攻撃や内部不正に対して、ログを組み合わせて利用することで見つけられるようにします。
セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ） - ＠IT
⇧ 上図にありますように、「通信経路」が分かる「情報」である必要がありますと。
そもそも、
ログを利用するセキュリティ業務とは
なお、この分類はこれまでの検討の中で、「アドホックなクエリに向いているかどうか」「サブクエリによる絞り込みが効率良く実施できるかどうか」「長期的な時系列データの保持に適しているかどうか」などを考慮してきた経験に基づいています。
セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ） - ＠IT
各業務の説明は以下の通りです。
セキュリティ運用における「ログ」とは
セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ） - ＠IT
⇧ 上図にあるように、各々の「業務」において必要な「情報」が取得できる「ログ」である必要がありますと。
「ログ」については、
ログとは
システム運用の現場では、よく「ログ」という言葉が登場します。そもそも「ログ」とは何なのでしょうか。「ログ」とは元来、船の航海日誌という意味です。コンパスなどの便利な道具がなかった昔は、丸太を船の船首から海に流して、船尾まで流れる時間を砂時計や初期の機械式時計で計測し、船の速さを測っていました。当時はその記録をログと呼んでおり、そこから転じて航海日誌という意味になったといわれています。つまり、ログとは何かの「記録」であり、システム運用においても何かを「記録」したものといえます。
ログの種類と利用用途
ログには、「いつ」「誰が」「どのような操作を行ったのか」などの情報が記録されています。ログの種類は多岐にわたりますが、下記はその一例です。
トラブル発生時の原因調査
システムで障害が発生した際に、その原因を突き止めるための情報源としてログはとても役に立ちます。また、システムで何らかのエラーが発生した際の原因調査にも役立ちます。
外部からの不正アクセスの把握
外部の第三者による不正アクセスによってシステムが不正利用されることは、企業としては何としても避けたいことです。不正アクセスは最悪の場合、個人情報流出などの被害が出る可能性があります。認証ログやアクセスログ、通信ログを取得することでシステムの不正利用の兆候を検知し、迅速な調査や対応の糸口をつかむことができます。
内部統制
不正アクセスは外部だけでなく、内部から起こる可能性もあります。例えば、社員が機密情報をUSBメモリに保存して、外部に持ち出したりすることが考えられます。実際、不正アクセスや情報漏えいは外部よりも内部から起こっていることが多いという調査結果もあります。
ログ運用の必要性
このようにログにはさまざまな利用用途がありますが、ログデータが消失したり、無断で書き換えられたりすると正しく記録された情報を漏れなく確認することができなくなります。
そこで「ログ運用」という考え方が出てきます。
ログ運用で最初に検討すべき4つの観点
ログ運用を検討・実施するにあたって、内容を明確にするために「ログ設定」「ログ転送」「ログ保管」「ログ利用」の4つの観点に分けると整理しやすくなります。
ログ運用の4つの観点
⇧ 上記サイト様が整理して下さっています。
ネットの情報を漁っていたところ、
⇧ 上記サイト様によりますと、
- 要件定義
- 非機能要件
で、「ログ設計」をしておく必要があるそうな。
まぁ、
セキュリティ・バイ・デザイン（英語: Security by design、SBD、もしくはセキュア・バイ・デザイン）とは、ソフトウェア工学におけるアプローチの一つであり、ソフトウェア製品およびその機能が、後付けの対策ではなく、その基礎からセキュア（安全）であるように設計されている状態を意味するものである。
概要
セキュリティ・バイ・デザインは、ソフトウェア開発初期フェーズ、すなわち設計・アーキテクチャ構築の時点でセキュリティ要件を組み込むことを中核とする。これは、開発の終盤やリリース後に脆弱性が発見されてから修正を行う従来のアプローチとは対照的である。
このアプローチでは、ソフトウェア設計の初期段階で代替的なセキュリティ戦略、戦術、パターンが検討され、その中から最良のものが選択される。選択されたセキュリティ設計はアーキテクチャによって強制され、開発者全体の指針として用いられる。また、元々はセキュリティを直接の目的として考案されたものではないデザインパターンであっても、結果としてセキュリティに有益な効果をもたらす戦略的デザインパターンを使用することも推奨される。
原則と目的
セキュリティ・バイ・デザインは、ソフトウェアシステムのセキュリティとプライバシーを確保するための主流な開発アプローチになりつつある。このアプローチでは、セキュリティは単一の機能としてではなく、システムのあらゆる層で考慮・構築され、堅牢なアーキテクチャ設計から始まる。
⇧ 上記にありますように、「セキュリティ・バイ・デザイン」という考え方も出て来ているようなので、然もありなん。
あとは、「運用フロー」についても明確にしておく必要はあるとは思うのよね...
結局のところ、どのような「運用フロー」が決まっていないと、「保守・運用」に関する「業務」が円滑に回らないと思いますし...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
