本セッションで話したいこと
木村安宏氏（以下、木村）：よろしくお願いします。それでは始めようと思います。「業界最大級（たぶん）の検証設備の運営とエンジニア育成」ということでお話しします。今日お話ししたいことは主に2つあります。1つがLabの紹介です。「検証設備」（という呼び方）では硬いので、これからはLabと呼ぼうと思います。このLabですが、プロダクトごとではなくて、共通で持っています。共通で持つことによってコストを抑えつつ、検証したい人・開発したい人がすぐに使える環境を提供しています。
もう1個の特徴ですが、Labそのものを使って検証しています。どういう意味かというと、Labの中に新しい技術や自分たちで開発したものを組み込んでいます。あとはユーザーのトラフィックやデータを活用しながら検証しています。
2個目に話したいことが、運営を通してのエンジニア育成の話です。どんなふうに技術にチャレンジしているか、運営側ではどんなことをしているかを話したいと思います。
スライド2
木村氏の自己紹介
自己紹介です。あらためまして、NTT Com（エヌ・ティ・ティ・コミュニケーションズ株式会社）のネットワークエンジニアの木村と申します。もともと学術系ネットワークとか研究機関を担当する、いわゆる構築エンジニアをやっていました。もっと技術を深掘りしたくて、2016年に社内の公募システムを使ってR&Dという今の部署に異動してきています。
そこからは開発エンジニアとして、NFV（Network Function Virtualization）とかSD-WAN（Software Defined-Wide Area Network）とかを担当しています。2018年ぐらいからキャリアネットワークの開発を始めて、どっぷりハマって現在に至っています。
仕事ですが、セグメントルーティングやホワイトボックス、ディスアグリゲーションなどをキーワードに、新しいキャリアネットワークを作ろうとしています。もう1個の仕事はLabの運営とエンジニア育成です。
興味がある分野は、大規模ネットワークにおけるE2Eでのトラフィック制御です。弊社はNTT ComとNTT docomoがくっついて、ネットワークの規模がますます大きくなってきています。大きなネットワークを使いつつ、E2Eでトラフィック制御をすることによって、つなぐだけじゃなく、付加価値がネットワークすることを目指しています。
エヌ・ティ・ティ・コミュニケーションズ株式会社の「Lab」とは
本題に入っていきます。「ネットワークキャリアのLabってどんなの？」ということを話していこうと思います。一般的なLabのイメージは、ラックの中に機器があるイメージだと思います。
我々はLabとしては、まずAS（Autonomous System）を運用しています。そのASの中に（は）ネットワーク基盤もあるし、コンピュート基盤も存在しています。また、基盤を運用するツールも含まれています。これら全部を合わせたものが我々のLabとなっています。
弊社のLabの構成要素を話していこうと思います。AS運用でいうと、まずAS番号を2個持っていて、2つのASの運用をしています。Office LANも持っていて、いわゆるファイアウォールを頂点に、スイッチとか無線LANを扱っています。拠点も複数あるので、拠点間をつなぐ拠点間ネットワークも自分たちで作り、運用しています。
大規模拠点はデータセンターになるので、DCにおいてはDCネットワークも使っているし、その上にコンピュート基盤があって、コンピュート基盤の中に運用ツールがあるといった構成要素になります。
（スライドを示して）少し詳しくしたものがこちらの資料です。まずASとして2つのトランジット。GINとOCNを契約していて、そのBGP（Border Gateway Protocol）の経路制御用に関東に2個、大阪に1個のトランジットポイントを設けています。少し変わっているなと思うものになりますが、ISP（Internet Service Provider）を5個契約していて、BGP（Border Gateway Protocol）の解析基盤を持っています。こちらを使ってBGPの経路の引きの強さとかをやっています。
拠点間ですが、大規模（な経路）に関していえば、SR-MPLSを使って拠点間を結んでいます。最近WhiteBox伝送にも力を入れていて、一部の拠点では伝送装置も使っています。
コンピュートに関してはVMware基盤を2つ持っているのと、それ以外にAzure StackとKubernetesの4つのコンピュート基盤を持っているのが我々のLabとなっています。
「Lab」の特徴
Labの特徴をお話ししたいと思います。我々のLabですが、マルチベンダ環境で、OSもいろいろなバージョンのものを使っています。運用の手間を考えると、ベンダを統一してOSに関しても枯れたものを使ったほうが楽ですが、我々はLab自体で検証しているので、いろいろな会社の機材を使います。
OSに関しては基本は最新のOSを使っていて、新しい機能が使えるのであれば、場合によってはβ版を使うこともあります。
また、物理だけじゃなくて仮想ルーターも使います。ホワイトボックスルーターとか、内製開発のものとか。最近ではディスアグリゲーションも使っています。こういったいろいろなものが混ざっているのが僕らのLabの特徴の1つです。
（スライドを示して）数字で表すとこんな感じで、拠点数は約30あり、ラックは400以上あります。ノード数は1,000以上あります。ユーザーの規模でいうと、だいたい500ユーザーぐらいが常時使っている感じです。設定変更とかのサービスオーダーが月に100件ぐらいある規模感になっています。
Labを使ってどんなことをしているか IPネットワーク編
じゃあLabを使ってどんなことをしているかの紹介をしたいと思います。まずはIPネットワークの紹介から。やっていることですが、継続してキャリアネットワークの開発を実施しています。どういう意味かというと、商用サービスより先に新しい技術に取り組んでいます。（そして）成果を出したら次に進むということをやっています。技術を選定して開発・構築して、新環境に移行して運用する。運用が安定したらまた次の技術を選定しています。
現状ですが、拠点間ネットワークで使っているSR-MPLSは2018年に作ったものです。このあとお話ししますが、新しいバックボーンを作っていて、これから移行を始めていきます。
過去の事例になりますが、2018年当初は導入事例が少なかったSR-MPLSを使ってバックボーンを作りました。シングルベンダ、シングルASのいわゆるシンプルな構成でL2VPN、L3VPNの提供をしています。このSR-MPLSですが、もう技術が枯れてきて、商用にも適用されているので、検証としての役割は終わっている状況です。
それで次に何をするかを考えました。キャリアの動向として、複数のネットワークの接続、AS間接続の需要が高まってきているのですが、技術的になかなか難しい部分があります。何が難しいかというと、ASが違うと当然ながらプロトコルが違う可能性があります。ベンダも違う可能性があります。
ここが（需要として）一番大きいと思っているんですが、AS内で運用を確立しているので、AS間接続することによって運用の体制とかを変更したくないという思いが強くあると思っています。こういった需要もあって、技術的なチャレンジもあることからこのテーマに今は開発を進めています。
（スライドを示して）それで作ったものがこちらになります。マルチAS、マルチベンダでのAS間接続モデルを作って、Labに導入しています。この絵でいうと、点線に囲まれているのが一つひとつのASになっています。先ほど言いましたが、AS内は独立性を保つので、内部に関しては特に変更することはありません。
このASBR間でMPLS Inter-AS Option Bを採用することによって、VPN経路の交換をして、AS間でのVPNを実現しています。このInter-AS Optionに関してはA・B・C・Dがありますが、我々が考えるASの独立性の確保とリソースの確保の観点から、Option Bを選択しています。
AS内ですが、2つのプロトコルを使い分けています。SR-MPLSとSRv6です。SRv6はまだ実装が足りない部分がありますが、注目している技術でもあるし、これからというところもあって採用しています。
今後は今のモデルをLabのバックボーンとして順次使っていくので、構築拡大をしていきます。トラフィックエンジニアリングという経路制御の手法を用いて、AS間でのトラフィック制御をやっていきます。拠点が複数あるので、拠点ごとにASを分けて、Lab全体での経路制御をやっていく予定です。
あとは、付加価値としてサービスファンクションチェイニングをやっていこうと思っています。これは何かというと、用途ごとにいろいろな機能、ファンクションをチェインするものです。
（スライドを示して）この絵のCustomer AでいうとNAT（Network Address Translation）、ファイアウォール、オプティマイザを通ります。Customer Bに関してはNATとDPI（Deep Packet Inspection）というかたちで、用途に応じてチェインするものを分ける機能があります。こういったものも使おうと思っています。
また、せっかくAS間での技術があるので、NTT Comだけじゃなくて、他の会社からもつなごうと考えています。
Labを使ってどんなことをしているか 伝送編
次に、伝送についてお話ししたいと思います。伝送する背景ですが、最近は帯域に広帯域な回線が求められています。それから8K映像の実験とか、ストレージネットワークといったものが挙げられます。また、技術の変化もあります。
ひと昔前、伝送はすべての構成要素を1個のベンダに揃えるのが当たり前でした。ですが、近年は伝送においてもWhiteBox化や標準化が進んでいます。
回路もだいぶ変わってきていて、ラインカード1枚分とか弁当箱サイズだったトランシーバもだいぶコンパクトになり、ルーターやスイッチに載る時代になってきています。
そういった背景があり、我々はマルチベンダでの光伝送システムを構築しました。スイッチポンダ、L2スイッチ、Mux/Demux、アンプを全部別のベンダで構築しています。装置間が1対（2芯）の光ファイバを用いて信号を多重化で接続しています。
まず、これは同一拠点のLabでやっているんですが、伝送は拠点間で使われるもの、長距離で使われるものなので、それを模擬するために樽で巻かれた光ファイバを使いました。これは20キロメートルある長いものなんですが、それを使ってまずは拠点内で試験をして成功しています。
実際に拠点間に適用したんですが、リンクアップしないという問題にぶつかりました。先ほどのものとの違いですが、まずは距離ですね。拠点間では約55キロメートルの光ファイバを使っていて、かつ光ファイバは同じシングルモードファイバではあるんですが、汎用のシングルモードファイバと分散シフトファイバが混合していました。なので、距離と混合（の問題）によって、光が減衰したことが原因だと考えています。
ケーブルを磨いたり、アンプの増幅量を調節したり、機器を再起動することによって、なんとかこのスイッチポンダ間ではリンクアップができました。ただしL2はまだできていないので、引き続き調査・実験をやっていこうと思います。
伝送の今後ですが、さらなる広帯域化を目指していこうと思っています。具体的にいうと、Disaggregated ROADMとかを入れることを検討しています。また、OpenZRというトランシーバが出てきているのでそれを使いつつ、IPoverWDMもやっていこうと考えています。
Labを使ってどんなことをしているか セキュリティ編
次がセキュリティの話です。このLabの環境は自由に検証できるようになってはいるんですが、セキュリティで何かを起こしてしまうとLabの存続そのものが危うくなるので、セキュリティはきっちりやっています。その事例を話したいと思います。
まずやっているのがセグメント分割です。ユーザーグループごとにセグメントを分けています。理由ですが、万が一ユーザーAが侵入を受けた場合に、他のユーザーに攻撃できないようにセグメントを分けています。また、端末には端末の振る舞い検知をするEDR（Endpoint Detection and Response）をインストールして、エンドポイントセキュリティをやっています。
また、Lab内にトラフィックポイントのTAP（Test Access Point）ポイントを置いています。このTAPはトラフィックをミラー、コピーできます。
コピーしたトラフィックをセキュリティ環境に突っ込んでいます。何をやっているかというと、フローベースでの振る舞い検知であるNDR（Network Detection and Response）によるアラート検出とか、シグネチャクエストの検出であるIDS（Intrusion Detection System）とか。
その他にも、DNSクエリとか一部に関してはフルキャプチャも実施しています。それに追加して外部から定期的にスキャンをかけていて、意図していないIPとかポートが空いていないかを見ています。
セキュリティの確保も大事ですが、チャレンジもしたいので、新しい技術もいろいろ導入しています。その際にメリットがあるのがユーザーということになります。実際にユーザーがたくさんいるので、多様なトラフィックとか実際の利用形態をもとに非常に実環境に近い環境を作れるのがLabの1つのポイントです。
いろいろ対策はしているんですが、本当に機能しているかを調べるために、BAS（Breach and Attack Simulation）製品を使って攻撃してみました。攻撃のシナリオですが、日本をターゲットにしているThreat Actorに関連している手法を採用しています。
まず1個目は、攻撃者がいきなり攻撃をしかけるのではなく、スキャンをして、空いているポートや脆弱になるオブジェクトを探しにいきます。まずはそれのスキャンをやります。その次にリスクの高いC2攻撃とか、あとは侵入されたあとの水平展開、Latetal Movementの攻撃も採用しています。
実際にやった事例をお話しします。内部に侵入されたことを想定した攻撃を実施しています。まず、DMZ（DeMilitarized Zone）になにかしら侵入された後インターネットに向かう攻撃を疑似の攻撃としてやりました。また、内部のユーザーがやられて、内部のユーザーからインターネット、DMZ（を通る）パターンの攻撃もしました。
結果ですが、セキュリティ設計思想とおおよそマッチした結果が出ています。特に横展開、Latetal Movementに関しては攻撃手法として防御できることはわかっています。オペレーション面で何個か気づきがあって、IDSでの検出はすごくアクションが取りやすいことがわかりました。IDSのアラートは攻撃内容や通信先、ファイル名などが出てくるので、それを基に次のアクションが展開しやすかったです。
一方でNDRですが、こちらに関してはなかなか取るべきアクションが難しかったです。理由（の1つ）としては、アラートの内容の転送量が多いといったものがありました。転送量が多いため、これが悪性のものなのか通常のものなのか、なかなか判断がつかないという問題がありました。
今後ですが、今お話ししたような検出ができない、検出が難しい脅威を把握するための技術を検討しています。今は独自の悪性判定情報を作っています。中身はIPアドレスやAS番号などが含まれています。それとの相関分析によって悪性判定をやっています。
先ほどのNDRでの転送量が多いものも、通信先がこの悪性判定情報とマッチしていれば悪性判定をするということも考えています。また、オンプレだけじゃなくてクラウド、SaaSにも攻撃検出機能を拡大する予定です。
もう1つが、セキュリティを検知したあとの対策の自動化を考えています。もし攻撃を検知したら、影響範囲とか被疑箇所を特定して運用者に情報を伝える仕組みを考えています。
（次回に続く）
