公開投票について

JANOG50 Meetingのライトニングトーク(LT)への応募数が採用数を超えたため、公開投票を実施します。

投票は締め切られました。結果公開までしばらくお待ちください。

投票期間

2022年6月17日(金) ~ 2022年6月24日(金)

選考方法

得票数の多いものから順番に採用します。得票数が同数の場合は、JANOG50プログラム委員で採否を決定します。
投票結果の発表は、2022年6月30日(木)の予定です。

応募ライトニングトーク一覧

No.タイトル概要
1 ゼロトラストセキュリティ- Zero trust security model- ゼロトラストセキュリティとは2020年 Forrester Research ,John Kindervagが提唱したセキュリティモデルで社内外問わず何も信頼せず常に検証し対応するモデルです。
NIST(米国国立標準技術研究所)がこのアークテクチャーを発表していて、このうちネットワークの場所に関係なく、全ての通信を保護する企業は資産やネットワークインフラストラクチャーについて可能な限りに情報を収集し、それをセキュリティ対策の改善に利用する
https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/zero-trust-architecture-jp.html

これらに関してはSEIM/UEBAおよびEDRだけでは対応出来ず、NDR(Network Detection and Response)の対応が必要になります。
NDRで検知対応が出来た例を共有したいと思います。
2 Terraform で快適NW検証 弊チームの検証環境では、Terraform の Libvirt provider を使って、仮想ネットワークアプライアンスを使った機能検証を快適に構築・変更・破棄しています。OVS との連携や、VNF に対して自動でコンフィグを投入する部分の作りこみ等のアーキテクチャについてご紹介するとともに、時間があれば実際に実施した検証について簡単にご紹介できればと思います。
3 光回線をサイバー攻撃から守るレイヤー1暗号化(レイヤー1セキュリティ) レイヤー1暗号化(レイヤー1セキュリティ)のメリットやレイヤー2、レイヤー3暗号化との違いについてお話します!

金融、政府、企業、法律、ヘルスケアの業界では、高いセキュリティのネットワークが必要とされています。データは組織の生命線であり、その損失や流出は、資本金、ビジネスリスク、評判の低下、計り知れない損失をもたらします。
また近年,ネットの利便性が高まる一方でサイバー攻撃の脅威が増大し,ネット全体に高水準のセキュリティレベルが要求されています。

しかし、光ファイバーは100%安全ではなく、通常の通信では光ファイバーをある程度曲げると、光ファイバーにダメージを与えず、信号伝送に影響を与えないように特殊な装置で光ファイバー内の信号を盗聴することができます。
「Optical Fiber Tapping: Methods and Precautions」から引用したデータによると、1-2%の漏れた光が、光ファイバを通過するデータの100%を持っているそうです。
大容量の情報の通信を担う光回線では、大量のデータが伝送されるため、攻撃者にとっては魅力的なターゲットとなっています。そのため、サイバー攻撃対策は強く求められています。

このような脅威を軽減するために業界では従来、レイヤー2、レイヤー3でデータを暗号化していました。従来の暗号化と比較して、レイヤー1をベースにした暗号化は、「〇〇、〇〇〇、〇〇」への影響を抑えながらセキュリティを保証できるというメリットがあります。
4
WAAP(Web Application & Application Protection)ってどうなの!?
WAAPは、ネットワークレイヤからアプリケーションレイヤのセキュリティに関連するもので、次世代のWAFとしても取り上げられたりしています。
WAAP自体、Gatnerが提唱し、サービス利用ユーザが増えてきています。
例えば、その中でWebアプリケーションやモバイルアプリケーションで利用されるAPIが主流になっている中、気付かずにその機能が使われ、ユーザアクセスをアタッカーから防御されていたりしています。
そのAPI連携に含まれるセキュリティ、BoT、WAF、ネットワークレイヤでのアタックを防ぐDDoSなど、さまざまなコンポーネントが複合的に利用できる仕組みとなっています。
実際にWAAPを利用する際メリットなどを一般的な話から運用者目線でのメリット、重要性についてお話しできればと思います。
5 AWS ECSのIPv6対応がムズカシイ MAP-E基盤のAWS移行に取り組んでいます。
現状オンプレのサーバで運用しているアプリケーションをAWS ECSに移行しようとしたところ、オンプレでは比較的容易な要件がAWSでは難しく・複雑な構成となる場面がありました。
苦労話や解決方法を紹介できればと思います。
6 「放送と通信の融合」は本当に来るの?ーブロードバンド代替検討の現場から 「放送と通信の融合」が言われ始めてから長い時間が過ぎました。
NHK+やTVerなどの放送事業者による番組コンテンツの配信が始まっていますが、正直なところ、それほどのマグニチュードを感じている人はいないのではないかと思います。
総務省では昨年11月から「デジタル時代における放送制度の在り方に関する検討会」という会議体が発足し、「ブロードバンド代替」という枠組みが検討されています。
具体的には、「放送事業者の放送設備を部分的に廃止し、インターネットとブロードバンドサービスを使った「放送」への置き替え」が検討されています。
今回の動きのモチベーション/原動力や、具体的な内容、地域の通信事業者の役割などを、本検討を行った当事者としてご説明します。
https://www.soumu.go.jp/main_sosiki/kenkyu/digital_hososeido/02ryutsu07_04000315.html
7 機器管理って悩ましくないですか? 弊社の環境を題材に年々増える機器たちの管理に関して取り組んでいることや、担当者目線からみた様々な悩みを共有させていただきます。
(資産管理、ケーブル管理、運用NW/監視NW、etc)
8 10,000人のクラウドPBXの登録をRPAに任せて定時で帰るエンジニアのお話 当セッションでは、寝る間を惜しんで期日と格闘していたエンジニアが、定時で帰ることができるようになるまでの軌跡をお話します。

本業である「エンジニアリング」に専念したいにも関わらず、膨大な量のリストのコピー&ペースト作業に追われた経験はありませんか?
私たちは、GUI/CLIに関わらず操作できる「Robotics Process Automation(RPA)」を活用することにより、エンジニアの生産性を飛躍的に高めることができました。

これまで運用や作業の自動化には、古くはジョブスケジューラやRBA、最近ではAnsibleやPuppet、Chefといった構成管理ツール等が活用されてきました。
特に、フロントや現場のGUIベースでのデスクトップ処理を自動化することはなかなか難しく、人の作業や関与が根強く残っていました。

今回、このように根強く残った人力作業もRPAで自動化することが可能になり、更には人的ミス防止や業務の棚卸など、副次的効果も高いことがわかりました。
ぜひこのLTにより、新たなRPAの活用方法の発見、エンジニアのみなさまの睡眠時間確保に繋げていただければと思います。

最後に、RPAによる新たな自動化の可能性として、今後は構成管理ツール自体をRPAで制御するような大きな野望も抱いておりますので、みなさまぜひご期待ください。
9 エッジクラウド活用のユースケース 低遅延やローカルでのデータ処理のための分散型エッジクラウドを活用したアプリケーション・サービスが様々検討されています。現在世界の事業者で行われているトライアルでのエッジクラウド活用のユースケースをご紹介します。
10 企業における実験的ASの活用 弊社では古くからAS24284を運用していますが、2021年より実験的ASとしてAS63790を設立しました。
このASは24284とは運用ポリシーを別とし、主要運用メンバーも全く異なるASです。

本LTではそんな実験的AS立ち上げの苦労や「けしからん」ネットワーク構築等について共有し、けしからん同志と知見を共有する場とさせていただきます。
11 ROVで経路をchange ~ 不正な経路を防ぐ!5分でわかるROA/ROVの効果 ~ BGPで交換される経路情報に誤った(または不正な)情報が混入してしまい、トラフィックに影響を与えてしまうというトラブルはたびたび発生しています。それを解決する技術として RPKIとその仕組みを活用したROA/ROVの普及が進んでいます。

ROAの発行数は年々増えていますが、最近ではこのROAを用いて経路が正当かどうかを判断する ROV (オリジン検証 – Route Origin Validation) を導入する大手クラウド事業者や海外の通信事業者も出てきました。

本LTでは、そんな導入が進みつつある ROA/ROV を使うと不正な経路をどのように防ぐことができるかご覧いただきます。
模擬環境での不正な経路による偽のWebサーバへのアクセスや、さらにROAを使った対策で経路をがどのように「チェンジ」されるか実際にご紹介します。この内容がROA/ROVの効果を実感するきっかけになり、導入の検討にお役に立てれば幸いです。
12 EVPN/VXLANでマルチベンダー検証してみた話 EVPN/VXLANを使用したDCネットワーク(IP-Clos)の構築・運用を行っております。
Leaf SWの増設機会が増えておりますが、半導体不足による納期遅延等もあるため、リスク分散の選択肢の一つとして、マルチベンダーでの構成を検討し、検証してみました。
Juniper+Arista構成で動作検証しましたが、構築~運用まで行っていくことを考えると、課題があると感じたので、これらについて技術的観点・運用観点で情報共有出来たらと思います。
13 neo4jで物理構成図描画自動化した話+妄想が捗った話 配線表を基に物理構成図の描画を自動化したいモチベーションがあり、配線表をneo4jに食べさせてお手軽に物理構成図の自動化をやってみた話です。使ってみての感想の他、色々ネットワーク運用に使えそうと妄想が捗った話や物理構成図以外のネタもいくつか試した話を交え、NW運用自動化の事例の一つとして共有したいと思います。
14 形式手法とクラウド時代のネットワークセキュリティ Amazon Web Service (AWS) をはじめとするクラウド上でのネットワーク設定は複雑で、ともすると意図しないアクセスを許可してしまうような脆弱性にも繋がりかねません。AWS では、このようなネットワーク上の潜在的な問題をワンクリックで検出する手段として、検査エンジン AWS Tiros が稼働しています。Tiros は形式手法と呼ばれるツール群の一種であり、実際のパケット送出を行うことなく設定のみから「論理的」に結果を導出できる点が特徴です。本 LT では、単に AWS エンドユーザの立場から見た Tiros の活用方法だけでなく、形式手法を用いたネットワーク検査の理論も含めて解説します。
15 携帯電話に使用された電波形式を振り返ってみてみる アナログ携帯電話から5G携帯電話までアクセスネットワークに、どんな電波形式(周波数・変調方式・送信電力 etc.)が使用されてきたか振り返って特徴をみてみる。
16 JAIPA Content/CDNトラフィックWGのご紹介と展望 昨今、インターネットトラフィック急増や、日本のインターネットトラフィックの様々な課題について、ISP/CATV事業者目線での対策検討を主目的とし、一般社団法人日本インターネットプロバイダー協会(JAIPA)でワーキンググループを設立しました。
ISP/CATV事業者におけるトラフィックのあるべき姿を追求し、トラフィック送信元のコンテンツ事業者やCDN事業者に対してこれらの啓蒙活動を行い、安定的なネットワーク運用と運用コストの低減を目標としています。
今回は、主な実施内容と今後エンジニアの皆様にご協力いただきたい点についてサマリーしてお伝えさせて頂きたいと思います。
今こそ一枚岩となり、声を上げましょう!
17 公衆無線LANの現在地 国内ではコンビニ等における無線LANサービスの終了が相次いでいます。一方、海外ではEUによる市民向けサービスWiFi4EUが3万スポット、WBA OpenRoamingによる国際間認証連携サービスに対応したスポットが1億を超えました。
国内サービスと何が違うのか、海外の動向やそこで扱われている技術をご紹介します。
18 注意喚起の文書化が案外難しかった話 たとえば函館NFTに魅力的に感じたときあなたはどうしますか?それは投機?それとも?
成人年齢が下がったいまの日本で、あなたが若者があやしいモノに手を出さないよう注意喚起する立場になったとき、どういう観点で文書化しますか?これが案外難しかった話をします。下手なことは書けないのです。
19 ネットワークが繋がらない・・・ ネットワークが繋がらない理由は様々・・・
設定が間違っている、コンフィグを誤修正してしまった、ファイアウォールの穴あけができていなかった、ACLを削除してしまった、などなど。
しかし今回は設定誤りなどの論理的なお話ではなく、機器を接続する配線や結線工事で実際に私が陥ってしまった状況や対処についてご紹介させて頂きたいと思います。

設計通りに結線したのにネットワークが繋がらない・・・!!

光ケーブル、SFP+、MPOコネクタ、ブレークアウトケーブル、パッチパネルなど多くの機器や部品が複雑に絡み合った構成の中で何が起こりどう対処したのかをお話しします。
20 はじめてのSDS(SoftwareDefinedStorage)!<クラウドサービス基盤でSDSを採用、運用してみたら…> 昨今、デファクトスタンダードとなりつつあるSDx(SoftwareDefined)技術や製品が数多くリリースされており、自社パブリッククラウドサービス提供基盤における、バックアップストレージをSoftwareDefinedStorage製品で構成すべく採用しました。
ある日、バックアップストレージでSSD障害であるSNMPtrapの発報がされ、SDSベンダーにログ送付したところSSD故障のため、ディスク交換が必要と回答を受けました。
ところが、HWベンダーにディスク交換依頼のためHW側のログを送付したところ、SSD故障のログは見られないため交換できないとの回答が…。
ここからSDSベンダー vs HWベンダーでログの問答で互いに譲らず、問合せから是正策実施まで3ヶ月を要してしまい、結果として、是正策を評価中にSSD障害を起因とした別の障害が発生してしまいバックアップサービス停止でお客様にご迷惑をかける結果となってしました。
このように、初めて取り扱うSDSへの不安との葛藤と開発後の運用における苦悩を皆様にご紹介します!

以上