サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト フェロー 関原 弘樹
こんにちは！
CSS
部エバンジェリスト フェローの関原です。
厳しい残暑が続きますが、酷暑と台風に悩まされた夏もそろそろ終わりです。
皆様いかがお過ごしでしょうか。
コラムタイトルのように日本語で「サマータイム」といえば個人的には真っ先に伝説のシンガー、ジャニス・ジョプリンによる
1968
年のナンバー
"Summertime"
を連想しますが、この曲はもともと
20
世紀の作曲家ジョージ・ガーシュウィンのオペラ「ポーギーとベス」のなかで歌われる悲しい内容のアリアで、現在までさまざまな歌手によって歌われています。
ジャニスはこの曲を含むアルバムでメジャーデビューをしましたが、今年は
2018
年なのでちょうど
50
年前の話でとなります。
さて、ここから本題に入ります。
本稿では今夏話題となった、
2020
のオリンピックに向けてのサマータイム
"summer time""daylight saving time"
の導入が議論された件についてその流れについて少し見ていきます。
■なぜ、サマータイム？
東京オリンピックは、2020/7/24～8/9でスケジュールされています。
今夏の東京では、この期間8/2の37.3℃を最高に酷暑となりました。
7/23には、なんと39℃を記録しています。
オリンピックはスポーツの祭典なので当然屋外の競技が多数ありますが、このようなコンディションでは各選手がベストなコンディションでは参加できないだろうということで、サマータイム案が出たようです。
オリンピックの競技はそれぞれスポンサーが協賛し全世界に放映されるため、特定の国で視聴に適さない時間帯である日本時間の夕方以降に実施するという選択肢は難しいようですね。
■サマータイムとは？
wikipedia※では以下のように解説されています。
「夏時間（なつじかん）またはサマータイム（英: summer time）、デイライト・セービング・タイム（米: daylight saving time (DST)、直訳: 日光節約時間（にっこうせつやくじかん）カナダ、オーストラリアでも用いる）とは、1年のうち夏を中心とする時期に太陽が出ている時間帯を有効に利用する目的で、標準時を1時間進める制度またはその進められた時刻のこと。
ただし、オーストラリアのロード・ハウ島では夏時間と通常の時間の差が30分であるなど一律ではない。
現在の主な実施国・地域では実施期間が7～8か月間のため、1年の中で通常時間より夏時間の期間のほうが長くなる。」
外部サイト：
※夏時間
しかしながら、下記の記事にもあるように、現在導入している国では節電や生産性の向上といった期待されるメリットに対し、実はあまり節電にならない、精神的に負担が大きい、といったデメリットが上回るようで、廃止したいという声が多数のようです。
外部サイト：
※EUはサマータイム「廃止目指す」 欧州委トップが表明 意見公募も8割超が「廃止」
日本でも前述のwikipediaに記載があるように、昭和23年～26年の間のみ導入をしていましたが廃止となった経緯があります。
■今回の検討内容は？
今回の日本のケースでは「2019～2020年の2年間の6～8月の3か月間のみ2時間」時間を繰り上げるという、世界でも例を見ないパターンでサマータイムを導入することを検討しているようです。
更に、検討内容の通り実施しようとすると開始まで1年もありません。
外部サイト：
※酷暑対策でサマータイム導入へ 秋の臨時国会で議員立法 ３１、３２年限定
■システム上の問題点とは？
私たちの生活面の対応はひとまず置いておいて、ITシステムの観点からはどのような問題があるでしょうか？
現在の主要なOS -Linux,Windows,macOS- やネットワークを通じて時刻を同期させるプロトコル -NTP- は
内部的に -UTC※- という協定世界時でシステムの時刻を扱っています。
正確にはUTCで特定の時点を起点とした経過秒数
Linux系 OS UTCの1970/1/1 00:00:00～
Windows OS UTCの1601/1/1 00:00:00～
macOS UTCの2001/1/1 00:00:00～
NTP UTCの1900/1/1 00:00:00～
UTCとは下記サイトに詳しく書いてあります。
外部サイト：
※UTC 協定世界時とは
各OSではロケーション（現在地）の設定をすることにより（日本であればUTC+9時間のJST「日本標準時」）PCの時計表示やファイルやログのタイムスタンプ表示が各国に対応した時間となり、同様にこの原理で時刻を繰り上げるするサマータイムにも対応可能となっています。
Linuxサーバ上でで現在のタイムゾーンをJSTからUTC-5時間のEST「東部標準時」（執筆のタイミングではサマータイム中でUTC-4時間のEDT表記）に変更してみたイメージです。
"DST active: yes"が現在サマータイム中であることを表しています。
その下はサマータイムの期間です。
意外と長期間だと思うのではないでしょうか。
Windowsの場合はこのようなイメージです。
さて、このようにエンドユーザの視点では問題無いように見えますが、それらを支える社会インフラについてはどうでしょうか？
電気・ガス・水道・運輸・放送・通信等、社会インフラのシステムでは独自のハードウェアやソフトウェアが導入されていることも多く、今まで日本で必要がなかったサマータイムに対応する機能があるとは限りません。
また、機能があった場合でも万が一の不具合を防ぐために、手順や設定ファイルを含めてシステム全体の十分な検証をする必要があることは想像に難くないでしょう。
となると、ハードウェアのリプレイス、ソフトウェアの開発、そしてその展開/検証作業には大きな工数＝コストがかかるのは自明の理です。
実施するとなったら、期間のない中でこれらの負担をどのように調整するかを重要な課題として認識する必要があります。
・例えば、夜間バッチを実施するシステムではサマータイム初日のタイムウインドウは2時間短くなります。影響範囲の特定と対策の立案にどれだけの工数が必要でしょうか？
・国外のシステムと接続するシステムにおいて、いきなりローカルタイムが2時間進んだ場合、リモートのシステムはどのような挙動になるでしょうか？事前にすべてのケースについてテスト可能でしょうか？
■その他の問題は？
2010年代のオリンピックといえばサイバー攻撃の話題は外せませんね。
ハクティビズムを目的とした公式サイトへのDDoSや改ざん。
都市空間のインフラであるOT（制御技術）を支配下に置いてからの人間や施設への物理的な攻撃。
観戦チケットの窃取・詐欺などによる経済攻撃。
これらの脅威が発生するシナリオが十分現実的なのは2012年ロンドン、2016年リオの例を思い出してみるとお分かりいただけると思います。
出展：https://www.nisc.go.jp/conference/cs/dai11/pdf/11shiryou03.pdf より
国家の威信をかけてサイバー攻撃によるインシデントを防がなければならないオリンピック期間に
サマータイムを導入することによるリスクをどのようにハンドリングしていくか？
セキュリティ責任者、担当部門にとっても頭が痛い問題となりそうです。
■世論は？
控えめにいって現在、今回のサマータイムの導入計画はWeb上を中心に無謀との意見が相次いでいるように見えます。
サマータイムの導入は恒久的にという話もあるようですが、リンクの記事どおりだとすれば2年間/計6か月間しか使用しない設定/機能ですから
前向きな話ではないですし、C/P的には議論するまでもないというところでしょうか。
そして、実際にシステムの対応作業をするSI企業の視点ではどうでしょうか？
契約によっては既存の保守契約の範疇として無償対応を迫られるのか… ビジネスチャンスとみて積極的にアプローチしていくのか…
どちらにしろ議論できる時間も少ないのは間違いないでしょう。どのような結論となるかは引き続き注視していく必要がありますね。
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara CRISC, CISSP, CEH, PMP, CCIE #14607
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
