お久しぶりです。データプラットフォームサービス部の花川です。 最近は気温の変化が激しいですね。みなさまも体調を崩さないようご自愛ください。 さて、今日は、11月7日(日)に開催した第1回TechWorkshop「現場のエンジニアと一緒に解く！コーディング体験」についてご紹介です! 本イベントは、今月下旬にも再度開催予定なので、この記事を読んで興味を持った学生の方は、参加申込をお待ちしております! *1 TechWorkshopって? 公式ページ の説明は以下の通りです。 各技術分野のプロフェッショナル社員がお届けする、当社の最先端技術を体感し、また身に付けることができるワークショップ形式のプログラムです。 過去にはこのようなワークショップを開催しました。 ISPネットワーク構築・運用体験 Kubernetesハンズオン ソフトウェアエンジニア座談会 CI/CDハンズオン どのワークショップも、公式ページの説明の通り、各分野を主な業務にしている/業務に使っている社員が講師となり、かつ自分たちでイベントの企画からしているものとなります。 今年度もいくつか開催予定ですので、興味のある方はぜひ参加申込をお願いします *2 。 「現場のエンジニアと一緒に解く！コーディング体験」とは このイベントは、TechWorkshopの中でも珍しい、NTT Comで実際にソフトウェアを開発している社員と学生さんでチームを組んで、とあるお題に沿ってコードを書いてもらうイベントです。 コードを書く体制として、 モブプログラミング(モブプロ) を採用しています。 つまり、社員/学生問わずワイワイガヤガヤと1つの画面を見ながらプログラミングのお題に挑戦してもらいます。 このワイワイガヤガヤを通して、「NTT Comのソフトウェアエンジニアがどんな感じなのか」だったり自分の技術のいい点や今後キャリアを考えたときの課題を感じてもらおうという趣旨です。 イベント自体は、数年前から開催しており、直近数回はとあるOSSをモチーフにした「お題」を作って取り組んでもらっています。 お題は、できるだけNTT Comでの開発の普段の業務に近くなるよう選んでおり、かつ取り組む背景も「業務で必要になった」体としています。 また、お題に対してStep by Stepで解けるように問題を設定しています。 とはいえ、これに沿ってただ作っていくのもつまらないので、"ちゃんと考えて作らないと"Stepを進めるにつれて難しくなるよう設定をしています。 当日の様子 今回のTechWorkshopは、学生さんが33人、社員が13人が参加しました。 また、このご時世ですのでZoomを使ったリモート開催となりました。 参加社員の多くはSmart Data Platformの開発に携わるエンジニアで、他にも社内フレームワークの開発やNWを活用したサービス開発のエンジニアも参加しています *3 。 当日のプログラムは、ざっくり以下の5つでした。 なお、当日のモブプロセッションでは replit というオンラインで同時編集できるIDEサービスを利用しています。 講義 モブプロ セッション1 モブプロ セッション2 解説 懇親会 (この記事では触れません) 講義パート まずは、モブプロを体験したことのない参加者も多いため、簡単にモブプロの紹介をしました。 その後、実際チームに分かれて、アイスブレイクということで自己紹介をしたり、練習問題に取り組んでもらったりします。 モブプロ セッション1 セッションでは、このようにワイワイと「これはこうだ」「いやこうだ」みたいな感じでディスカッションしながら楽しんでいるようでした。 セッションが終わった後は、同様にチームでコードレビューやふりかえりを実施して、社員を含めた参加者全員で学びを共有したりしました。 ちなみに、出題の意図通り、とあるStepで設計が行き詰まるチームも多かったようです。 モブプロ セッション2 後半も、チームメンバーをシャッフルした上で同じお題にチャレンジしてもらいました。 前半の経験やふりかえりを元に、きれいな設計や実装ができているチームが多かったようです。 見づらいですが、上手く動いて「ヤッター」とみんなで喜ぶなど、和気あいあいとした雰囲気でコードを書いています。 セッションの終わりには再度コードレビューやふりかえりを実施してもらいました。 問題の理解度も深まっていたのか、コードレビューではより具体的に「普段社員が設計や実装のときに注意していること」や、普段の業務風景などいろいろな質問のやり取りが行われていました。 解説 解説では、今回の問題のテーマとなったOSSの紹介や、なぜこういった題材にしたのかを簡単に説明しました。 が、ネタバレになるのでここの説明は省略します! 気になる人はぜひこのイベントに参加してください! 参加者の声 参加アンケートには、こんなコメントが寄せられていました。 多くの方に「ためになった」「楽しかった」と思ってもらえたようで、企画した社員一同とても嬉しいです。 メンバーの方と意見を出し合いながら開発を進めることができ、チーム開発やモブプログラミングの楽しさを感じた 同じ学生同士でコーディングの仕方の違い、伝え方、聞き方、考え方について色々感じることができた 実際に運用されているサービスをもとにしたテーマを扱ったため、考え方など勉強になった おわりに この記事では、11月7日(日)に開催された第1回TechWorkshop「現場のエンジニアと一緒に解く！コーディング体験」について、紹介しました。 例年このようなイベントを企画運営していますが、参加する学生のみなさんが楽しくなると同時に、社員も楽しい時間を過ごせるイベントとなるよう心がけています。 やはり、自分たちが楽しむことで、イベント全体がより良いものになりますからね。 今後も、TechWorkshopを始めとして、参加する人たち全員が楽しめるイベントを企画運営していければと思っています! ここで耳寄り情報ですが、同じ内容で11月28日(日)に第3回 TechWorkshop「現場のエンジニアと一緒に解く！コーディング体験」として開催予定です。 応募締切は11月14日(日)となっていますので、この記事を読んで興味を持った学生の皆さんはぜひご応募ください! www.ntt.com *1 : 参加申込多数の場合、抽選にて決定いたします *2 : TechWorkshopは学生が対象となっています *3 : 懇親会後の写真なのでみんなゆるい感じで写っています

はじめに こんにちは、イノベーションセンターの鈴ヶ嶺・齋藤です。普段はコンピュータビジョンの技術開発やAI/MLシステムの検証に取り組んでいます。10月11日から17日にかけて、コンピュータービジョン分野におけるトップカンファレンスのひとつである ICCV2021 がオンラインで開催され、NTT Comからは複数名が参加しました。ここでは、会議の概要と参加メンバー2名からICCV2021の論文紹介をします。 ICCV2021 ICCV（International Conference on Computer Vision）は、2年ごとに開催されるコンピュータービジョン分野におけるトップカンファレンスのひとつです。2021年は10月11日から17日にかけて、オンラインで開催されました。 アクセプトされた国の比率は上記のようになっており、中国とそれに続いてアメリカが多数を占めていました。一昨年のICCV2019からおよそ1800件の投稿が増えて6152件が投稿されました。そのうちの26%である1612件の論文が採択される結果となりました。また、口頭発表には3.4%の210件が選ばれました。 論文紹介 ここからは参加メンバーが気になったICCV21の論文と実際にコードを動かした結果を紹介します。 COMISR: Compression-Informed Video Super-Resolution(ORAL PAPER) COMISRとは 今までの多くの映像の超解像手法は圧縮を考慮せず、低解像の動画から高解像の動画に変換しています。しかし、日常で使用しているwebやモバイルのコンテンツの多くは圧縮されています。この論文では、そのようなコンテンツを対象として、圧縮情報を用いた映像の超解像手法を提案しています。 COMISR 1 は、Recurrentモデル 2 をベースにしています。一般的な動画圧縮には、イントラフレームと呼ばれる他のフレームを予測するのに用いられる参照フレームを使用します。イントラフレームは独立に圧縮され、他のフレームはそのイントラフレームからの差分情報のみを使用して復元することから高い圧縮率を達成することが可能となります。このイントラフレームの位置はランダムに選択され事前には分からないため、Recurrentモデルのような前後関係を踏まえた特徴を抽出可能なモデルが使用されます。また、Recurrentモデルはメモリ消費も少なく動画の様々な推論タスクに適しています。 次の画像が、手法の全体像です。提案手法は、主に3つのモジュールのBi-directional Recurrent Module, Detail-aware Flow Estimation, Laplacian Enhancement Moduleから構成されます。 原論文から引用 Bi-directional Recurrent Module Bi-directional Recurrent Moduleを用いることで前方と後方からのフレーム予測に対して一貫性を強制し、精度を向上させています。まず初めに、入力された低解像の画像を後述するDetail-aware Flow Estimationにより高解像のオプティカルフローを推定します。次に、推定した高解像画像に後述するLaplacian Enhancementによりラプラシアン残差を付加してspace-to-depthを経て高解像画像の生成処理をします。 Detail-aware Flow Estimation Detail-aware Flow Estimationでは、隣接する低解像、高解像の画像の差分を表現したオプティカルフローを推定することであるフレームの次のフレームを生成します。上記の全体像ではフォワードの際の例が示されており、隣接する低解像の画像2つを連結したものを入力としてフローを推定します。その際には、直接フローをアップサンプリングするのではなく追加でdeconvolution層を通します。このようにして、end-to-endな学習や高周波の詳細な特徴を獲得することが可能となります。 Laplacian Enhancement Module ラプラシアン残差は、多くの視覚タスクで使用されており非常に有用な詳細情報です。しかし、この情報はアップスケーリングネットワークでは容易に失われてしまうため、ラプラシアン残差を高解像の予測フレームに追加することで補完します。具体的には次の式のようにガウシアンフィルターを用いて残差を追加します。 原論文から引用 実験結果 提案したCOMISRモデルをVid4 3 、REDS 4 をCRF23で圧縮したデータセットを使用して既存の超解像モデルと比較した結果が次のようになります。提案手法は大幅な性能向上を達成しました。 原論文から引用 次に、Vid4のいつかの結果を示します。定性的に比較してCOMISRが最も復元されていることが分かります。 原論文から引用 実際に動作させた結果 次のツールを事前に準備しておきます。 ffmpeg gsutil 以下が実際に動作させたものになります。 git clone --depth 1 https://github.com/google-research/google-research.git cd google-research/comisr # install package pip install -r requirements.txt # オリジナル動画を準備します (origin.mp4) # cp /path/to/origin.mp4 . # 解像度の確認 ffprobe -v error -select_streams v:0 -show_entries stream =width,height -of csv = s =x:p = 0 origin.mp4 # 1920x1440 # オリジナル動画を低解像に変換します (lr_4x.mp4) ffmpeg -i origin.mp4 -crf 0 -vf scale =480:-1 lr_4x.mp4 # 解像度の確認 ffprobe -v error -select_streams v:0 -show_entries stream =width,height -of csv = s =x:p = 0 lr_4x.mp4 # 480x360 # 低解像動画を圧縮します (lr_4x_crf25.mp4) ffmpeg -i lr_4x.mp4 -vcodec libx264 -crf 25 lr_4x_crf25.mp4 # download pre-trained model gsutil cp -r gs://gresearch/comisr/model/ . # input, target dataを準備します mkdir -p data/hr/linux_kernel ffmpeg -i origin.mp4 -r 60 data/hr/linux_kernel/img%05d.png mkdir -p data/lr_4x/linux_kernel ffmpeg -i lr_4x.mp4 -r 60 data/lr_4x/linux_kernel/img%05d.png mkdir -p data/lr_4x_crf25/linux_kernel ffmpeg -i lr_4x_crf25.mp4 -r 60 data/lr_4x_crf25/linux_kernel/img%05d.png # 出力先を用意します (output_dir) mkdir output_dir # 推論実行開始 export PYTHONPATH= $( dirname $ ( pwd )) python inference_and_eval.py --checkpoint_path=model/model.ckpt --input_lr_dir=data/lr_4x_crf25 --targets=data/hr --output_dir=output_dir # 結果 ## output_dir/linux_kernel/output_img00001.png ## output_dir/linux_kernel/output_img00002.png ## ... 今回は、詳解Linuxカーネル第3版の本を対象として実験してみました。以下は結果の抜粋です。 オリジナル画像 低解像画像 出力結果 ぱっと見ると、なかなか綺麗に処理されていると思われます。次に、もっと細部に注目して見ていきましょう。 こちらの結果は左下の「O'REILLY オライリー・ジャパン」という文字に着目しています。アルファベットの「O'REILLY」については綺麗に復元されていることが分かります。カタカナの「オライリー・ジャパン」については、「ミライリー・ジャパン」のように読める文字として復元される結果になりました。おそらく、「オ」は潰れてしまい人間の目で見ても非常にわかりづらいので復元するのが難しい結果となったと考えられます。その他のカタカナについては人間が見ても読める文字に復元されています。 こちらの結果は水晶を磨く人物画像に着目しています。水晶の細かな模様についてはあまりに潰れすぎており復元が難しいですが、人物の顔や服の模様などがある程度綺麗に復元されていることが分かります。 所感 超解像の対象として圧縮されたコンテンツに着目した手法を提案している実用面での有用性を感じました。 また、フレーム予測による圧縮技術から着想を経てBi-directional Recurrentを採用した点や高周波情報を追加する工夫がされている点が素晴らしいと感じ紹介させていただきました。 SOTR: Segmenting Objects With Transformers SOTRとは SOTR 5 とは、Segmenting Objects With Transformersの略で、インスタンスセグメンテーションのタスクにおいて、CNNとTransformerを組み合わせたモデルの提案を行なっています。SOTRは、この論文でTwinTransformerを新しく提案し、そこではEncoderが画像の縦方向と横方向のみをAttentionするようになるため、時間とリソースの効率を良く且つ精度の向上を達成したことが示されています。効率よく計算できる理由として、縦横の2次元のAttentionの計算オーダから画像の縦横方向の2つをそれぞれ1次元にAttentionの計算する((縦方向の要素数x横方向の要素数) 2 から (縦方向の要素数) 2 +(横方向の要素数) 2 )ためです。 原論文から引用 まず見ていただきたいのは、Figure 1の図です。ベンチなどの大きいオブジェクトに対しては、これまでのMaskR-CNN 6 などのモデルでもセグメントが可能でした。しかし、画像左上と右上にあるような、小さい画像に対してのセグメントの精度は高いとは言えませんでした。これについては、後ほどSOTRを動かしてみるので、目で見てわかるほどの違いを体感可能です。SOTRでは、画像の左上や右上の図のようにかなり小さいオブジェクトに対しても、セグメントを高精度に行うことができています。それを可能にしたのが、CNNとトランスフォーマーを組み合わせたモデルとなります。 原論文から引用 原論文から引用 モデルの概要について説明します。まず、BackboneはFPNの機構を用いて、P2~P6までの特徴量マップを求めます。先程Transformerでは、Positional Embeddingを行いTwin Transformerを実行し、Kernel HeadとClass Headを出力します。SOTRで提案されているTwin Transformerでは、各パッチとその行と列のみをAttentionしています。インスタンスのクラス分類は、ここで説明を行なったTransformer ModuleのClass Headから行います。Multi level Upsampling Moduleでは、Transformer Moduleから出力された低解像度なP5の特徴量マップを取得し、各層P2〜P4でアップスケーリングと結合を最終的にH×W特徴マップを作ります。マスクの予測のために、Transformer Moduleから出力された、Kernel Headを畳み込みKernelとMulti level Upsampling Moduleから出力されたH×W特徴マップを掛け合わせ、マスクを生成します。 実験結果 原論文から引用 上のテーブルはTwin TransformerとMask R-CNNやSOLO 7 などのインスタンスセグメーテーションのモデルの精度を比較したものとなります。学習用データセットは、MS COCO train2017 8 。評価用データセットは、test-devを使用しています。論文著者の学習環境は、32GのRAMを搭載したNvidia V100、4枚で学習されフレームワークにはPyTorchとDetectron2を用いています。結果として、SOTRがテーブルで示している他モデルよりも6つの評価指標のうち5つ(AP,AP50,AP75,APM,APL)において高い精度を示していました。 実際に動作させた結果 まず、SOTRはdetectron2上で動作させるためにはdetectron2, SOTRのセットアップをする必要があります。インストールするスクリプトを流しても良いのですが、PCの環境が汚れてしまうため、今回はDocker&Jupyter Notebookを立て、検証しました。自身の実行環境は、Ubuntu18.04、Single NVIDIA RTX3090です。 FROM nvidia/cuda:11.1.1-cudnn8-devel-ubuntu18.04 MAINTAINER Satoru Saito ENV DEBIAN_FRONTEND noninteractive RUN apt-get update && apt-get install -y \ python3-opencv ca-certificates python3.7-dev git wget sudo python3.7-distutils python3-pip cmake git wget sudo ninja-build && \ rm -rf /var/lib/apt/lists/* #python install RUN python3.7 -m pip install --upgrade pip RUN python3.7 -m pip install numpy RUN ln -sv /usr/bin/python3.7 /usr/bin/python && \ python -V # create a non-root user ARG USER_ID=1000 RUN useradd -m --no-log-init --system --uid ${USER_ID} appuser -g sudo RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers USER appuser WORKDIR /home/appuser ENV PATH= "/home/appuser/.local/bin:${PATH}" RUN wget https://bootstrap.pypa.io/get-pip.py && \ python get-pip.py --user && \ rm get-pip.py # install dependencies # See https://pytorch.org/ for other options if you use a different version of CUDA RUN pip install --user tensorboard cmake pycocotools RUN pip install torch==1.8.0+cu111 torchvision==0.9.0+cu111 torchaudio==0.8.0 -f https://download.pytorch.org/whl/torch_stable.html RUN pip install --user 'git+https://github.com/facebookresearch/fvcore' RUN pip --no-cache-dir install absl-py==0.10.0 backcall==0.1.0 cachetools==4.0.0 chardet==3.0.4 cloudpickle cycler==0.10.0 cython dataclasses decorator==4.4.2 future==0.18.2 fvcore==0.1.dev200325 grpcio==1.27.2 idna==2.9 ipykernel==5.2.0 ipython==7.13.0 ipython-genutils==0.2.0 jedi==0.16.0 jupyter-client==6.1.1 jupyter-core==4.6.3 kiwisolver==1.1.0 markdown==3.2.1 matplotlib numpy==1.18.2 oauthlib==3.1.0 opencv-python pandas==1.0.3 parso==0.6.2 pexpect==4.8.0 pickleshare==0.7.5 pillow==7.0.0 portalocker==1.6.0 prompt-toolkit==3.0.4 protobuf==3.11.3 psutil==5.7.0 ptyprocess==0.6.0 pyasn1==0.4.8 pyasn1-modules==0.2.8 pydot==1.4.1 pygments==2.6.1 pyparsing==2.4.6 pytz==2019.3 pyyaml==5.3.1 pyzmq==19.0.0 requests==2.23.0 requests-oauthlib==1.3.0 rsa==4.0 scipy==1.4.1 seaborn==0.10.1 six==1.14.0 tabulate tensorboard tensorboard-plugin-wit==1.6.0.post2 termcolor==1.1.0 tornado==6.0.4 tqdm==4.43.0 traitlets==4.3.3 urllib3==1.25.8 wcwidth==0.1.9 werkzeug==1.0.0 yacs==0.1.6 networkx==2.3 python-Levenshtein Polygon3 shapely graphviz # install detectron2 RUN git clone https://github.com/facebookresearch/detectron2 detectron2_repo # set FORCE_CUDA because during `docker build` cuda is not accessible ENV FORCE_CUDA= "1" # This will by default build detectron2 for all common cuda architectures and take a lot more time, # because inside `docker build`, there is no way to tell which architecture will be used. ARG TORCH_CUDA_ARCH_LIST= "Kepler;Kepler+Tesla;Maxwell;Maxwell+Tegra;Pascal;Volta;Turing" ENV TORCH_CUDA_ARCH_LIST= "${TORCH_CUDA_ARCH_LIST}" RUN pip install --user -e detectron2_repo # Set a fixed model cache directory. ENV FVCORE_CACHE= "/tmp" WORKDIR "/home/appuser" ENV PATH= "/home/appuser/.local/bin:${PATH}" # Jupyter Notebook RUN pip install jupyter && \ mkdir /home/appuser/.jupyter && \ echo "c.NotebookApp.ip = '*'" \ "\c.NotebookApp.port = '8888'" \ "\nc.NotebookApp.open_browser = False" \ "\nc.NotebookApp.token = ''" \ > /home/appuser/.jupyter/jupyter_notebook_config.py EXPOSE 8888 WORKDIR "/home/appuser/detectron2_repo" RUN git clone https://github.com/easton-cau/SOTR.git RUN cd /home/appuser/detectron2_repo/SOTR && \ sudo python setup.py build develop 以上のDockerfileをbuild&runします。 TerminalからJupyterの起動し、任意のディレクトリに SOTR_R101_DCN をダウンロードをします。また、自身の解析したい画像のパスを --input に指定し以下のコードを走らせると推論を始めます。 python SOTR/demo/demo.py \ --config-file SOTR/configs/SOTR/R_101_DCN.yaml \ --input hoge.jpg --output ./SOTR/outputs/ \ --opts MODEL.WEIGHTS ./SOTR/SOTR_R101_DCN.pth 今回私は、MSCOCO val2017から一枚を選び推論をしました。一枚目の画像は、Methodが、MaskR-CNNでBackboneがResNet50 9 。2枚目は、MethodがSOTRでBackboneがResNet DCN101となります。2枚を比較すると、奥にいる小さい人のセグメントが上がっていることが分かります。直感的にも、精度が向上していることが分かりました。ここからは、私の考察になってしまうのですがTwin Transformerが、MaskR-CNNと比較し小さい物体のセグメントをできている理由として、Transformer層で画像の縦横をピクセル単位でAttentionを行なっているため、局所的な特徴量の抽出が可能になっているのではないかと考えられます。今回は、定量的な評価はしないのですが、機会があれば検証したいです。 maskR-CNN ResNet50 SOTR ResNet DCN101 所感 ここでは、インスタンスセグメンテーションのタスクにおいて、CNNとTransformerを組み合わせたモデルについて説明しました。オリジナルのTransformer Encoderよりも、メモリの消費量を減らし且つ、精度の向上が論文中に示されていたので、興味を持ちご紹介しました。 最後に ここまで前編では、ICCV2021の概要と発表された論文の一部をご紹介しました。後編も引き続き気になった論文を紹介するのでぜひご覧になってください。 NTT Comでは、今回ご紹介した論文調査、画像や映像、更には音声言語も含めた様々なメディアAI技術の研究開発に今後も積極的に取り組んでいきます。 アカデミックな研究に注力したくさん論文を書きたい 最新の技術をいちはやく取り入れ実用化に結び付けたい AIアルゴリズムに加え、AI/MLシステム全体の最適な設計を模索したい という方々に活躍していただけるフィールドがNTT Comには多くあり、一緒に技術開発を進めてくれる仲間を絶賛募集中です。 Li, Yinxiao, Pengchong Jin, Feng Yang, Ce Liu, Ming-Hsuan Yang, en Peyman Milanfar. “COMISR: Compression-Informed Video Super-Resolution”. In Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV), 2543–52, 2021. ↩ Takashi Isobe, Xu Jia, Shuhang Gu, Songjiang Li, Shengjin Wang, and Qi Tian. Video super-resolution with recurrent structure-detail network. In ECCV, 2020. ↩ Jie Liu, Wenjie Zhang, Yuting Tang, Jie Tang, and Gangshan Wu. Residual feature aggregation network for image superresolution. In CVPR, 2020. ↩ Seungjun Nah, Sungyong Baik, Seokil Hong, Gyeongsik Moon, Sanghyun Son, Radu Timofte, and Kyoung Mu Lee. Ntire 2019 challenge on video deblurring and superresolution: Dataset and study. In CVPR Workshops, 2019. ↩ Guo, Ruohao, Dantong Niu, Liao Qu, en Zhenbo Li. “SOTR: Segmenting Objects With Transformers”. In Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV), 7157–66, 2021. ↩ Kaiming He, Georgia Gkioxari, Piotr Dollár, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE international conference on computer vision, pages 2961–2969, 2017. ↩ Xinlong Wang, Tao Kong, Chunhua Shen, Yuning Jiang, and Lei Li. SOLO: Segmenting objects by locations. In Proc. Eur. Conf. Computer Vision (ECCV), 2020. ↩ Tsung-Yi Lin, M. Maire, Serge J. Belongie, James Hays, P. Perona, D. Ramanan, Piotr Dollár, and C. L. Zitnick. Microsoft coco: Common objects in context. In ECCV, 2014. ↩ Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. Deep residual learning for image recognition. In Proceedings of the IEEE conference on computer vision and pattern recognition, pages 770–778, 2016. ↩

はじめに こんにちは。プラットフォームサービス本部 データプラットフォームサービス部でSmart Data Platform (SDPF) のサービス企画を行っている安井・小野です。閲覧頂きありがとうございます。 DX推進にはデータ利活用が不可欠です。その実現には多くの困難が伴います。 当社では、そんな状況の解決をお手伝いすべくSDPFを提供しています。ここでは、当社が提供しているSDPFを皆様に知って頂くために、具体的な利用例と取り組みについてご紹介します。 Smart Data Platform (SDPF) とは SDPFは、企業に点在するデータを1つのプラットフォーム上でシームレスに融合。データを整理して利活用しやすくすることで、 日々の活動から産まれるデータを企業成長のエンジンに変える、次世代のプラットフォームです。 多くのお客様にご利用頂いてます当社の回線サービス(Arcstar Universal One、OCN、モバイル)を起点として、クラウド上に多くのデータを蓄積し、 そのデータを使用目的に応じて利活用するデータ活用基盤のような形でご利用いただけます。 SDPFは約60ものサービスの集合体で、データ利活用に有効なサービスを多くラインナップしています。 2021年5月にはサービスラインナップ、ポータルサイト、お客様導線の見直しを実施し、よりお客様が使いやすいサービスにすべく改善を続けています。 お客様にご利用頂くために - 複雑化する業務課題への対応 お客様が自らの業務課題を解決するにあたり、これまではお客様自身やSIerの方々が数多くのサービス機能を1つ1つ確認しながら、 自身で組み合わせを行い最適なサービス組み合わせを探してこられたかと思います。 我々はそのお手伝いをさせて頂くことを目的に、お客様の業務課題をあらかじめ想定して、複数サービスを組み合わせた動作確認や機能検証を行いました。 そして、これらの取り組みで得られた知見や手順を Smart Data Platform Knowledge Center にTIPSとして記載する取り組みを実施しています。 以降では複数サービスを組み合わせて検証できる環境を作るところから始めた、サービス企画チームの取り組みをご紹介します。 検証を通じた確認 実際に検証環境を作ってみた 「オンプレ/DC疑似環境(SDPF-LAB＠川崎)　～　 Flexible InterConnect (FIC) 　～　SDPFクラウド/サーバー」 ユーザー環境に近づけるため、下図のようにあえてオンプレ環境や専用線についても作成し、構築の工数や注意点などを実際に確認してみました。 実際に検証を実施してみた ①クラウドへのリフト＆シフトの実現、閉域網やクラウド型ストレージを利用したバックアップ基盤の活用 Arcserve UDP を用いてオンプレ環境のバックアップデータを、 FIC経由で Wasabiオブジェクトストレージ(Wasabi) に保存、 さらに IaaS Powered by VMware (IPV) 環境にリストアを行う検証をしました。 ②クラウドへのリフト＆シフトの実現、開発環境のクラウド化と匿名化した本番データの活用 SDPFサービスの1つである データ匿名化ツール(tasokarena) を利用。 Terraform、AnsibleといったInfrastructure as Code (IaC)ツールを活用し、環境構築の簡易化と匿名データ活用の検証をしました。 ③多様なサービスに対応するログ蓄積基盤の構築とその活用 Wasabiへのデータ格納ツールやWindows・LinuxへのWasabiマウントツール、さらにログ管理ツールといった複数のツールを活用することにより、 ログの蓄積・活用するための検証をしました。 確認後の具体的な気づきポイント ①の事例ではArcserve UDPやWasabiについてのまとまった情報が記載されているサイトが少なく、かつ確認に時間を要しました。 例えばWasabiのバケットに対するアクセス制限のポリシー設定や、FIC経由でWasabiにバックアップを行う場合に、 Wasabiのアドレスをルーティング設定する必要がある等、時間を掛けて要件確認していきました。 以下はWasabiのバケットに対するアクセス制限のポリシー設定の書き方となります。 Wasabi Management Consoleで対象バケットを選択して「Settings」マーク（歯車のマーク）をクリックし、 「POLICIES」タブをクリックして、表示された画面でポリシーを設定します。 ※「IPアドレスx/サブネット」の個所でアクセスを許可したいIPアドレスで設定する。複数ある場合はカンマ（,）で区切って指定します。 ---- { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "IPアドレス1/サブネット", "IPアドレス2/サブネット" ] } } } ] } ---- 他にもArcserve UDPの各エージェントで管理者アカウント以外のユーザーを使用する場合等、注意点がありました。 このように利用者目線で実際に使ってみて分かったことが多々ありました。 こういった点を、お客様が使いたいときに速やかにご利用できることを目指してKnowledge Centerへ記載しました。 お客様への見える化 Knowledge Centerでは検証を通して得られた知見や手順を記載していますが、オファリングサイトでは概要的な利用イメージをご理解いただくための内容を記載しています。 概要的な部分を確認したい場合はオファリングサイトをご確認ください。 オファリングサイトへの記載 Knowledge Centerへの記載 最後に 実際の構築活動を通じて、複数のサービスを組み合わせる際の手順的なコツであったり、組み合わせによっては注意点が存在したりすることが分かりました。 これからもお客様目線で実際に手を動かし、実用性のあるSDPFの組み合わせ構成を作っていき、 分かりやすくお伝えするためにKnowledge Centerへの記載拡充を行っていきます。 「ここの記載がわかりにくい」等のご意見や、「SDPFでこんなことができないか」等の疑問がありましたら、以下メールアドレスに対してお気軽にコメント等ご連絡ください。 sdpf-testbed-02＠ntt.comにメールを送る ※お手数ですが＠を全角文字から半角文字に置き換えてください。 ありがとうございました。

はじめに こんにちは、インターン生の櫻井幸大です。普段は大学院で 社会基盤インフラマネジメント について研究をしています。 今回私は 9月16日から30日にかけて、約2週間に渡り行われた職場体験型インターンシップ（エンジニアコース）に参加させて頂きました。この記事ではインターンシップの体験記として、どんな内容に取り組んだのか、職場の環境はどのような感じなのかをご紹介します。 インターンシップ参加の経緯 梅雨に入ろうとするくらいの時期に就活を始めた私は（と言ってもただ某大手就活サイトに登録申請を送りやった気になっていただけですが）、夏前までは「インターンシップか～、どこかの会社に行ってみなくちゃな～」と漫然と思い過ごしていました。しかしいざ大学が夏休みに入ると、周りの友人が次々とインターンを開始する中で「もしかして自分もそろそろマズいのでは」と焦りを抱え始めました。 自分のやりたいことに思いを巡らせる中、インフラ工学を専攻している立場として、「 インフラ関連の会社なら自分も何かにコミット出来るのかも 」「 どうせインフラを扱うなら時代の超々最先端を行く情報基盤について勉強したい 」と思い描くようになりました。 そのままの流れで情報基盤の会社を検索し、技術や知識もなくただ熱意だけを込めた ESを書き上げ、志望部署の欄に「ネットワーク基盤」と丸をつけそのままエイヤっと提出したところ、とても幸運なことに合格の通知を頂くことが出来ました。 以上の経緯で、NTTコミュニケーションズさんのところで二週間の実習に励む運びとなりました（ちなみに体験型ワークショップの方には見事に落選しました）。 インターンシップに参加する前は NTTコミュニケーションズという会社について知っている単語はOCNのみで、長距離の通信をやっている会社なんだな～というぼんやりとした理解に留まっていました（それも公式のYoutubeで見た情報です）。 NTTコミュニケーションズが MVNO事業をやっているということも知らずにmobile関連の部署で実習させて頂くこととなり「ほんとによくこんな体たらくで合格なんてもらえたな…」と今でも思っています。 インターンシップで取り組んだこと インターン前半期 このようにネットワークの基礎中の基礎も知らないままインターンシップに参加することとなった私ですが、もちろんこのまま業務に携わるわけにはいかないので、基礎の基礎を勉強するところからスタートしました（ここで初めてネットワークの階層モデルを知りました。当時の私はほんとにそういうレベルでした）。 勉強はトレーナーの方がほぼ付きっきりで見て下さったので、実際に使用される機器に触りながら、他に類を見ない速度で知識・技術を身に着けることが出来ました。とても楽しくワクワクしながら勉強できたことを今でも強く覚えています。トレーナーの方のピンポイントかつ丁寧で熱心な教育していただいたおかげもあり、たった一週間でゼロレベルの状態から BGPを用いた簡単なルーティングが出来るようにまでなりました。 ネットワークの基礎を学ぶのと同時に、配属されたグループの方々にはPCRF（モバイルのポリシー制御システムを司る機能）の更改についてや、今をときめく5G・Local 5Gの技術についての説明を受ける貴重な機会を頂きました。特に現状の携帯網で使われているEPC（スマートフォンから送られるパケットが基地局からインターネットに抜けるまでに通過する部分）の中の仕組みについてのお話や、これが5Gになって5G COREへとガラリと変革する、といった内容がとても面白かったです。 総じて、前半期では 技術の基礎から今起こっている問題や実際の事業現場のお話まで、非常に幅広い内容のお話を聞く機会を提供して頂けました。 配属されたグループにおいて、たくさんの人からが何をどう思いながらお仕事に取り組んでいらっしゃるのかを吸収することが出来ました。この期間で自分の中で会社のイメージはかなり大きく良く変わりました。 インターン後半期 インターンシップの後半では「次期ネットワークに更改するにあたり検討されているClos Fabricネットワークを構成する機器が、ルーティング広告の負荷に耐えられるのかを検証するシステムを構築する」という実際の業務に少しだけ関わらせて頂きました（といっても自分の方から何かを提案させていただくというものではなく、実際の開発の現場を体験するといった内容です）。 ネットワークは構成機器がそれぞれのルーティングテーブルを正しく保持することでパケットのやり取りが可能となり、これが正確でなければきちんとパケットが正しく伝達できません。 今回新しく導入が検討されているClos Fabricネットワークでは、EVPN/VXLANというプロトコルを用いてルーティングのアドバタイズが行なわれています。ネットワークが正しく使えるかどうかを確かめるためには、アドバタイズされた通知を受けて各構成機器がきちんとルーティングテーブルを更新しているかどうかを検証することが必要です。 プロトコルエミュレータを用いて行うこの検証を自動化する仕組み（アドバタイズをもとにルーティングテーブルが更新されているかを確かめる仕組み）について、今回自分が実習の中で制作に携わらせて頂きました。 開発は、Dockerを用いて仮想化された実行環境上で行いました。コンテナ技術とは OSの上で開発環境の切り離しを行いプロセス分離による処理の軽量化を実現した仮想化技術のことであり、これによってハードウェアの状態と切り離した状態の中で開発環境を動かすことが可能となります。こうすることで開発する個人の状態に依存しない開発環境の整備が出来るようになっていました。 更に、今回携わったチームにおける開発環境では、GitLabを利用することで多人数での同時的なコード開発・デバッグを実現する環境が整っていました（流石はソフトウェア開発分野の最先端の最前線）。Gitのシステムを初めて使わせてもらうこととなり、開発のツリーに自分の足跡をほんの少しでも残せたことが、とても嬉しかったです。 ちょうど自分のインターンシップ時期が次期ネットワークへの移行を模索している段階と重なったということで、ネットワークの網が張り替わる、まさに時代の変わり目に立ち会えたかのように感じました。 また、ネットワークが更改される作業にほんの一部分ですが携わることができ、そこに携わる社員の方々からたくさんのお話を伺うことを通じてシステムの増築・保守・維持管理・あるいはその先の未来に向けて俯瞰的な眼差しを持って基盤を創るのが大切だなぁ、と学びました。 今日の情報インフラ分野ではもの凄いスピードで技術革新が生み出され続けていく中で、自分も負けじと知識・技術を吸収し続ける、勉強し続け現場に応用していくことが改めて必要であると気づかされたような気がしています。 インターンシップを振り返って インターンシップを終えて私の抱く NTTコミュニケーションズの今のイメージは、「 将来の情報基盤に向けて挑戦を重ねる会社である 」と感じています。インターンシップ期間中に何度か配属されたグループの定例会に参加させて頂いたのですが、そこでの議題の内容が非常に濃く自分の中で印象に残っています。 システム間のリクエスト処理の仕組みや次期装置の更改に向けてのアジェンダを話し合う方々の姿を見て、 次の社会の下支えを積極的に創る熱意 を私は感じ取りました。その中のほんの小さな一端にでも自分の二週間が関われたことを、とても嬉しく感じました（Gitのログに名前を刻めたことが自分の何よりの宝物です）。 インフラは何かをするための基盤であり、なくてはならない下部のレイヤーです。だからといって使えればいいという簡単なものではなく、将来や時代を見据えた俯瞰的で総合的なアプローチが重要であると私は考えます。NTTコミュニケーションズは情報基盤を積極的により良くしようと果敢に挑戦されている、ということを会社で働く方々のお話を聞いて肌で感じましたし、「 志を高く熱意を持って社会に貢献したい 」という方にオススメの会社であると私は感じます。また、凄い人から凄い内容を学ぶ仕組みが充実しておりますので、「 自分の技術力を向上させていきたい 」という技術的な上昇志向の高い人にもオススメの会社と言えます。 また、今回のインターンシップは最初から最後まで全てリモート環境での実施とはなりましたが、それでも多くの方々に熱心に実習を支えて頂き、 社員の方々の温かさ というのも非常に色濃く感じました。 Slack等で何かを聞けばすぐ的確に答えて下さるトレーナーさんの優しさや、インターン生一人ひとりに業務用のパソコンを送付してくださったヒューマンリソース部さんのご厚意もあり、快適に、とても楽しく実習に取り組むことが出来ました。本当にありがとうございました。 さて、これから秋も深まる中、就職活動も次のフェーズへと移行していきます。今回のインターンシップでは無知の状態から情報インフラの分野に飛び込んでみて、ほんの少しの基礎を学ぶのと同時に、情報分野の果てしない広大さに打ちひしがれました。しかし、たくさんの人のお話を直に伺う中で「熱意」に関してはより一層高まったように感じます。 もちろん道は険しいのですが、「今の自分に何が足りないのか」はなんとなくでも見えてきたような気がしてますし、インターンで学んだ内容を精一杯活かしてより一層社会貢献できるようなエンジニアになれるよう、勉強にも尽力していければと思っています（もちろんESにも技術面からのアピールポイントを書けるように頑張ります）。NTTコミュニケーションズの皆さん、二週間という短い期間でしたが、本当にありがとうございました。 トレーナーからのコメント 今回インターンシップを担当した プラットフォームサービス本部データプラットフォームサービス部の溝口です。 櫻井さんは、ネットワーク関連の技術スキルは確かにほとんどゼロの状態でしたが、この2週間でネットワーク装置の検証の自動実行プログラムの作成ができるところまでスキルアップしてもらうことができました。これは櫻井さんの、物怖じせず疑問に思った点は何でも質問できるキャラクタによるものが大きいと感じました。今後ともぜひ続けていってほしいですね。 インターンシップを通じて開発部門において大きな割合を占める検証という業務を経験して、企業の中でエンジニアがどのように業務を行っているかイメージをもっていただくことができたのではないでしょうか。この経験を活かしてより一層就職活動や研究に励んでいただければ、トレーナーとしても嬉しい限りです。

はじめに こんにちは、インターンシップ生の田畑（GitHub: TBT0328 ）です。 9月16日から30日の2週間、NTTコミュニケーションズのインターンシップに参加させていただきました。 この記事では、インターンシップでどのようなことをしたのかを紹介します。 概要 今回私は、NTTコミュニケーションズ イノベーションセンターで制御システムネットワークのセキュリティ可視化技術である OsecT （オーセクト）の開発に関する業務を行いました。 今回のインターンシップは新型コロナウイルス感染拡大防止のため、全日リモート形式での実施でした。 参加のきっかけ 大学の研究室の先輩から「実際の業務（もしくはそれに近い業務）に携われるからとても楽しいよ！」と熱い（？）アピールを受け、ぜひとも参加したいと思い応募しました。 参加前の面接では、インターンシップでの業務内容を複数提示していただき、インターン生がやりたい内容に合わせてくれる柔軟性の高いインターンシップだと感じました。 インターンシップ内容 OsecT内で動くツールや仕様の一部変更、最新のLTSへのアップデートをDockerを使用してプログラム作成などを行いました。 ソースコードの管理はGitHubを使用しており、研究室でのコード管理とはまた違った、実際の業務環境で作業しました。 私自身、DockerやGitHubを使った経験があまりなく、GitHubへのPullRequestの投げ方や、Dockerfileの書き方などの基本的なことから教えていただきました。 下図はGitHubへのPushやDockerfileの書き方に悪戦苦闘して長くなってしまったコミット履歴です。 また、人が書いたコードの読み方や実装後のテスト方法などを教えていただきながら、OsecTのサービス化に向けて役に立てるようなことができたと感じています。 業務環境 全日リモート形式での開催ということで、自宅から参加しました。 NTTコミュニケーションズから、インターンシップで使用するPC、インターンシップ期間中の昼食代相当のチケットを支給していただきました。 OsecTの開発は自前のPCを使い、トレーナーの方やチームの方々とはSlackで連絡を取り合いました。 また、期間中毎日、インターンシップの進捗報告と今後の方針を相談する朝ミーティングを開いていただきました。 下図は朝ミーティング後のタスク確認の様子です。 イベントへの参加 期間中はすべてリモートということで、実際にオフィスに行くことはなかったのですが、複数の社内イベントに参加させていただきました。 NTTコミュニケーションズの技術顧問との対話会 インターンシップ生を対象にしたスペシャルイベントとして、NTTコミュニケーションズの技術顧問の方々との対話会を開催していただきました。 技術顧問との対話会と聞いて堅いイベントだと思っていたのですが、とてもカジュアルな対話会でした。 技術顧問の方々が実際にどのような業務・支援しているのか、技術顧問の方々が感じるNTTコミュニケーションズの印象など、リアルな職場を知ることができる対話会でとても勉強になりました。 イノベーションセンター内業務共有会 インターンシップ後半に差し掛かり、イノベーションセンターに所属するインターンシップ生同士での業務内容の共有会を開催していただきました。 期間中どのような業務を行ったか、どのようなことを学んだのかを発表していくという流れで、自分以外のインターン生が行った内容や、他チームが行っている業務について知ることができるイベントでした。 期間中はOsecTに関する業務を行っていたので、他インターン生が参加したプロジェクトやその有用性を多く学べる機会でした。 KOELによるデザイン研修 イノベーションセンター内のデザイン部門である KOEL の方々によるデザイン研修会を開催していただきました。 「デザイン思考」や「デザインプロセス」についてや、KOELがデザインした 「NeWork」 を開発する段階での具体的なデザイン思考についてお話をしていただきました。 アイデアの創出の前にすべきことや、それぞれのデザインプロセスで有用なフレームワークについて学ぶことができ、研究室での活動では得難い視点でとても新鮮で勉強になりました。 TechLunch NTTコミュニケーションズではランチの時間帯に、気軽に参加できる勉強会であるTechLunchが不定期に開催されており、インターン生も参加させていただきました。 今回は「リモートネイティブ新入社員のリアル」というテーマでイノベーションセンターの新入社員の方々に各々取り組んだ仕事についてお話していただきました。 新入社員が感じたリモート形式のメリット・デメリット、不安に感じることなどをお聞きでき、社員のリアルを知れました。 また、お話を聞きながら、他の社員の方が「〇〇に関してはもう少し深堀りしたほうがいいね」などと発言していらして、意見を発信しやすい環境なのだと感じました。 インターンシップを振り返って 今回のインターンシップを通して、様々なことを学ぶことができました。 Dockerを使った開発の進め方や、Gitを用いたコード管理などの技術的な部分はもちろん勉強になったのですが、それよりも、業務の進め方や業務を行う上での考え方がとても勉強になったと感じています。 作業が詰まったときに素早く相談する大切さ タスクとタスクの間の空き時間や、テスト中の空き時間をいかに利用するか タスクの優先順位、取捨選択、割り振りのスピーディーさ リモートでプロジェクトメンバとのこまめな連絡、簡潔かつ必要な情報の先出し意識の高さ これらを学べました。 また、社員同士の活発な、まめな連絡を見て、意見を発信しやすい環境なのだなと再認識しました。 おわりに 夏季インターンシップの内容や感想について書かせていただきました。 約2週間、OsecTに関する業務に携わらせいただいて、技術的にも成長できました。 また、業務を行う上で必要なスキルを持っているか、足りないスキルや考え方はどのようなものなのかを学ぶことができました。 今後の研究活動などにも活かす事ができるとても有意義な経験をさせていただきました。 NTTコミュニケーションズの皆様、大変お世話になりました。ありがとうございました。 トレーナーからのコメント 田畑さんのトレーナーを務めた鍔木（GitHub: takuma0121 ）です。 まずはインターンお疲れさまでした。 10日間という非常に短い期間でしたが、GitHubやDockerだけでなくパケット解析ツールのZeekなど初めて使うツールを学びつつ、OsecTの実装というアウトプットまで出せました。 また、フルリモートということで対面での業務はできませんでしたが、朝ミーティングやSlackを通じてコミュニケーションしつつ上手く業務に取り組めたのではと考えています。 このインターンの経験を研究や将来の仕事に少しでも活かしていただけると、トレーナーである私も嬉しいです。 インターンお疲れさまでした！

マネージド&セキュリティサービス部 セキュリティサービス部門 インシデントレスポンスチームの濱崎と戸祭です。 今回は、 前回 紹介したビジネスメールサービス「Microsoft Exchange Online」の監査ログについて、の後編となります。 前の記事（ 前編 ）ではログの種類と取得方法について説明しました。 後編ではログを記録しておくための設定方法について説明します。 目次 目次 前編の要約 ログの設定 Exchange Online Powershellへの接続 Unified Audit Log（統合監査ログ）の有効化 Mailbox Audit Log（メールボックス監査ログ）の設定 ログの保持期間の延長 まとめ 前編の要約 前編 では、以下のログの概要と、NTT Comでの調査に最低限必要なログの取得方法を説明しました。 Unified Audit Log（統合監査ログ） AzureADサインインログ Mailbox Audit Log（メールボックス監査ログ） Admin Audit Log（管理者監査ログ） Message Trace（メッセージ追跡） 後編では、これらのログを記録しておくための設定方法を説明します。 ログの設定 前編 で紹介したログは、既定では取られていない可能性があるため、ログを確実に残せるよう設定の確認と変更を推奨します。 またログの保存期間も既定では短いため、保存期間の延長を検討する必要があります。 この節では、Powershellを用いた適切なログ取得設定と保存期間の延長方法について紹介します。 Exchange Online Powershellへの接続 まずExchange Online Powershellに管理者権限をもつユーザでログインします。 > Install-Module -Name ExchangeOnlineManagement > Import-Module ExchangeOnlineManagement > Connect-ExchangeOnline -UserPrincipalName <User Principal Name, メールアドレス等> Unified Audit Log（統合監査ログ）の有効化 Unified Audit Logは、現在では基本的には既定で有効 1 です。 しかしライセンスや過去の設定によっては有効でない場合があるため確認を推奨します。 UnifiedAuditLogIngestionEnabled がTrueになっているかを以下のコマンドで確認します。 > Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled UnifiedAuditLogIngestionEnabled : True Falseになっていた場合、次の方法でTrueにしてください 7 。 > Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true （ただしNTT Com IRチームの検証用環境では上記コマンドの前に Enable-OrganizationCustomization の実行が必要でした。また反映まで数時間待つ必要がありました 8 。 エラーが出る場合はお試しください。） Mailbox Audit Log（メールボックス監査ログ）の設定 Mailbox Audit Logは、設定上では有効になっていても検索ができない、既定では取れない項目があるなど一部わかりにくい箇所があります。 基本的な設定をはじめとした、いくつかのポイントをご紹介します。 組織の既定の設定で監査が無効になっていないかを確認 監査の有効無効は、組織の既定、および各メールボックスごと、各ユーザごとに設定できます。 ただし公式のドキュメント 9 に以下のようにあることから、現在は各メールボックスごとの監査の有効無効の設定は無視され、常に組織の既定の設定が優先されるようです。 Turning off mailbox auditing on by default has the following results: Mailbox auditing is not enabled for new mailboxes and setting the AuditEnabled property on a new or existing mailbox to True will be ignored. Currently, you can't disable mailbox auditing for specific mailboxes when mailbox auditing on by default is turned on in your organization. そのため一番重要になる組織の既定の設定で、メールボックス監査が無効にされていないかを確認します。 > Get-OrganizationConfig |Select-Object -ExpandProperty AuditDisabled False もしTrue（監査が無効）だった場合、以下の方法でFalseにします。 > Set-OrganizationConfig -AuditDisabled $false ユーザごとに監査をバイパスしていないかを確認 組織の既定の設定で監査が有効になっている場合でも、ユーザごとに監査を無効にできます。 以下の方法でこの機能がFalseになっていることを確かめます。 MailboxIdentityとしてユーザ名やメールアドレスを渡します。 > Get-MailboxAuditBypassAssociation -Identity <MailboxIdentity> | Format-List AuditByPassEnabled AuditBypassEnabled : False もしTrue（監査をバイパス）になっていた場合、Falseに切り替えます。 > Set-MailboxAuditBypassAssociation -Identity <MailboxIdentity> -AuditBypassEnabled $false ユーザごとに行う必要があるため、スクリプトで自動化することを推奨します。 監査ログ検索を可能にする 既定でメールボックスの監査は有効になっていますが、公式ドキュメント 9 には以下のように注意書きがあります。 If mailbox auditing already appears to be enabled on the mailbox, but your searches return no results, change the value of the AuditEnabled parameter to $false and then back to $true. つまり監査が有効になっているように見えても、Microsoft 365 コンプライアンスセンターやPowershellコマンドレット等での監査ログ検索ができない場合があります。その際はメールボックスごとの監査の有効無効( AuditEnabled パラメータ)を切り替えて再び有効にすることが必要です。 #有効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true #無効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $false #再び有効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true メールボックスごとに行う必要があるため、スクリプトで自動化することを推奨します。 「高度な監査」を有効化 E5/A5/G5といったライセンスを使用すれば、「高度な監査」を使用してより詳しいログの調査が可能です 10 。 中でも有用なものは、 MailItemsAccessed イベントと SearchQueryInitiated 系イベントです。 MailItemsAccessed イベントはメールの閲覧を記録します。 読まれたメールが特定できる ため、漏洩した情報の特定に利用できます。 SearchQueryInitiated 系イベントは検索内容を記録します。攻撃者がどのような情報を探していたのか、意図をつかみやすくなります。 ただし、単一のメールボックスで1,000イベント/日と大量の監査レコードが生成された場合、そのメールボックスに関する MailItemsAccessed のログ生成が打ち切られるという注意点があります 11 。 「高度な監査」が有効になっているかは、次の手順で確かめることができます 12 。 Microsoft 365 管理センター > ユーザー > アクティブなユーザー > ユーザーをクリック > ライセンスとアプリ から右に出るペインのアプリ欄を見て、Advanced Auditingにチェックが入っていることを確認します。 高度な監査が有効になっている例 メールボックス操作の記録設定 Mailbox Audit Logは、ユーザ種別ごとにどんな操作を記録するか設定できます。 確実に必要なログを残すため確認することを推奨します。 公式ドキュメント 13 では以下の記述があるため、特にメールボックスオーナーについての設定は注意が必要です。 メールボックスオーナーの操作を監査すると、大量のメールボックス監査ログ エントリが生成される可能性があるため、既定では無効となっています。 （なお、NTT Com IRチームの検証環境では最初からメールボックスオーナーの監査が有効化されていたようでした。） ユーザ種別は3つあり、 AuditAdmin , AuditDelegate , AuditOwner です。 ユーザ種別ごとにロギング可能な操作一覧 9 を参考に、少なくとも同ページ表中の * マークが付いているものが有効になっていることを確かめてください。 次のようにして、ロギングされる操作の一覧を表示できます。例として以下ではメールボックスオーナー ( AuditOwner )に関して表示しています。 > Get-Mailbox <identity of mailbox> | Select-Object -ExpandProperty AuditOwner Update MoveToDeletedItems SoftDelete HardDelete UpdateFolderPermissions UpdateInboxRules UpdateCalendarDelegation ApplyRecord MailItemsAccessed Send もしメールボックスオーナーに関して MailItemsAccessed がロギングされない設定であった場合、以下のコマンドで有効にします。 > Set-Mailbox -Identity <identity of mailbox> -AuditOwner @{Add="MailItemsAccessed"} （コマンドでデフォルト設定と完全に同一か確認したり、デフォルト設定に戻したりすることも可能です。本記事のスコープ外なので詳しくは公式ドキュメント 9 を参照してください。） また、前セクションで触れた SearchQueryInitiated 系イベントのロギングをメールボックスオーナーに対して有効化します。 > Set-Mailbox -Identity <identity of mailbox> -AuditOwner @{Add="SearchQueryInitiated"} 以上の操作は全てのユーザのメールボックスに対して行うことが望ましいため、スクリプトでの自動化を推奨します。 ログの保持期間の延長 デフォルトでの保持期間は以下の通りです。 設定を変更する、ライセンスを契約する等でできる限り期間を伸ばしておくのが安心です。 ログ名 デフォルト保持期間 延長方法 UnifiedAuditLog (統合監査ログ) 90日-1年 2 ライセンス契約 *1 MailboxAuditLog (メールボックス監査ログ) 90日 9 AuditLogAgeLimit の値を増やす 13 AdminAuditLog (管理者監査ログ) 90日 3 - （オンプレミス版Exchangeなら可） 6 MessageTrace (メッセージ追跡) 90日 4 - Azure AD サインインログ 30日 5 - 将来のインシデント時にデータが残っていないと取れる対処の選択肢が狭まってしまいます。 以上を参考に、できる限り長期間のログを保持するようにしておくことをお勧めします。 更に長期間ログを保持したい場合、SIEMを使用することを推奨します。ログの活用も容易になります。 まとめ 前編 ではMicrosoft Exchange Online に関するログの種類と取得手順を説明し、後編ではログを記録しておくための設定方法を説明しました。 2つを併せて、来たるインシデントへの備えとしてご活用ください。 ログの分析については、各ログの意味の理解や、大量のログを処理しながらの頻度分析、アノーマリ分析、インテリジェンスを活用しての調査が必要となります。機会があれば別記事で解説したいと思います。 [1] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/turn-audit-log-search-on-or-off?view=o365-worldwide [2] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/audit-log-retention-policies?view=o365-worldwide [3] : https://docs.microsoft.com/en-us/exchange/security-and-compliance/exchange-auditing-reports/view-administrator-audit-log [4] : https://docs.microsoft.com/ja-jp/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results [5] : https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-reports-data-retention [6] : https://docs.microsoft.com/ja-jp/exchange/policy-and-compliance/admin-audit-logging/admin-audit-logging?view=exchserver-2019#admin-audit-log-age-limit [7] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/search-the-audit-log-in-security-and-compliance [8] : https://forum.devolutions.net/topics/31378/how-to-use-powershell-with-office-365-through-rdm [9] : https://docs.microsoft.com/en-us/microsoft-365/compliance/enable-mailbox-auditing?view=o365-worldwide [10] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/advanced-audit?view=o365-worldwide [11] : https://docs.microsoft.com/en-us/microsoft-365/compliance/mailitemsaccessed-forensics-investigations?view=o365-worldwide [12] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/set-up-advanced-audit?view=o365-worldwide [13] : https://docs.microsoft.com/ja-jp/exchange/policy-and-compliance/mailbox-audit-logging/enable-or-disable?view=exchserver-2019 *1 : Unified Audit Log（統合監査ログ）についてはライセンスによって異なり、E5などの上位のライセンスで高度な監査が有効な場合（既定で有効）、一部のRecodeTypeをもつログの保存期間が1年となります 2 。また特別なアドオンライセンスを契約すれば、最大で10年間保持することが可能です 10 。

マネージド&セキュリティサービス部 セキュリティサービス部門 インシデントレスポンスチームの濱崎と戸祭です。 今回は、Microsoft社がMicrosoft 365 (Office 365) 内で提供するビジネスメールサービス「Microsoft Exchange Online」の監査ログについて、不正アクセスの観点でお話します。 本記事は前後編に分かれており、前編ではログの概要と取得について説明します。 後編 ではログを記録しておくための設定について説明します。 はじめに Microsoft Exchange Onlineへの不正アクセスが発生した場合、いつ発生したか、どのアカウントが被害にあったか、どのようなデータが閲覧・持ち出されたか、どのような攻撃の踏み台にされたか、などを明らかにする必要があります。 ところが、Microsoft Exchange OnlineはAzureAD等いくつかのコンポーネントが連携しあって提供されており、調査に必要なログもまとまって管理されていません。また、Microsoft公式ドキュメントでも、どこにどのようなログが保存されているかインシデントレスポンスの観点で体系的にまとめられたものがありません。加えて、GUIでのログ閲覧機能では一部の情報が欠落するなどの問題があることが知られています。 いざというときにこのような調査ができるよう、事前に把握・準備しておくべき次の内容について簡単にまとめて紹介します。 不正アクセス調査に備えて取得すべきログの種類 （前編） ログの取得方法（前編） ログの設定方法（ 後編 ） なお、本記事の内容は、2021年9月執筆時点での公開情報とNTT Com IRチームで検証用に取得したライセンスでの検証結果に基づきます。商用ライセンスのグレードや契約形態によって、一部異なる事実が含まれる可能性があります。また、Microsoft社は不定期に仕様を変更しています。今後も仕様が変わる可能性がある点、ご了承ください。 目次 はじめに 目次 Microsoft Exchange Onlineとは 不正アクセス調査時に有用なログ Microsoft 365のUnified Audit Log (統合監査ログ) Azure Active Direcotryのサインインログ Exchange Onlineの監査ログ Exchange OnlineのMessage Trace ログ （メッセージ追跡ログ） ログ取得 Powershell vs 管理コンソール（ブラウザ）vs API ログ取得実施手順の概要 事前準備 1. 全ユーザに関するログの取得 2. 攻撃に関与した疑いのあるユーザのログ取得 まとめ Microsoft Exchange Onlineとは 　Microsoft Exchange Onlineは、Microsoft社が提供するメールホスティングサービスであり、同社が古くから提供しているMicrosoft Exchange Server機能をクラウド上で提供するものです。構築や運用の難易度が高いExchange Serverの管理から解放されること、また事業の継続性の確保(BCP) や柔軟な働き方を支援するインフラに適していることから、多くの企業に導入されています。 　一方で、攻撃者目線に立つと、世界中のどこからでもアクセス可能なメールサーバの存在は、メールデータの窃取が従来に比べて行いやすくなることを意味します。実際、ニュースや報道においてMicrosoft 365への不正アクセス事例が数多く報告されており、NTT Comにおいても相談数が増えているのが現状です。また、以前にNTT Comの旧技術ブログで紹介したように、ラテラルフィッシング攻撃も問題となっています。これらの攻撃の有無を確認するためにログが重要な情報源となります 1 。 不正アクセス調査時に有用なログ Microsoft Exchange OnlineはMicrosoft 365の一部として提供されています。また、Microsoft 365はAzureADをID管理として利用しているなど、いくつかのコンポーネントが連携しています。それぞれのコンポーネントがログを取得しており、ログの粒度や内容も異なることが、インシデントレスポンスにおけるログ調査を複雑にします 2 。 Microsoft 365, Exchange Online, Azure AD, ログ閲覧できる管理用サイトの関係性の図 上図のように、Azure ADやExchange Online等の各種サービスのログ情報の一部が、左のUnified Audit Logに収集されます。 しかしUnified Audit Logのみを見ればよいわけではありません。完全に同じログが収集されるわけではないためです。 以降では、それぞれのコンポーネントにおけるログサービスの名称や機能のうち特に不正アクセス調査に有用なログを紹介します。 Microsoft 365のUnified Audit Log (統合監査ログ) Microsoft 365が提供する各アプリケーション（Exchange Online, Sharepoint等）の監査ログを統合管理したもの 各アプリのそれぞれのログのうち、 一部が Unified Audit Logに転送される AzureADのサインインログやExchange Onlineの転送ルールの作成等が含まれるため、調査に有用 主に次の3つの方法で閲覧、ダウンロード可能 *1 Microsoft 365 コンプライアンスセンター > ソリューション > 監査 Exchange Online Powershellを利用したダウンロード 3 APIでのダウンロード Unified Audit Logの表示例 Azure Active Direcotryのサインインログ 4 ユーザのサインインに関する記録を提供 サインインに関する、日時、ユーザ名、送信元IPアドレス、サインインに使用したアプリケーション名、ブラウザ名等が記録されている 意図しないサインインかどうかの判定に利用可能 次の3つの方法で閲覧、ダウンロード可能 Azure AD 管理センター 5 > 監査ログ > サインイン Powershellを利用したダウンロード 6 APIを利用したダウンロード Azure AD 管理センターから閲覧可能なサインログ Exchange Onlineの監査ログ 主にMailbox Audit Log(メールボックス監査ログ)と Admin Audit Log(管理者監査ログ)に記録 各メールボックスに対するログインやメールアイテムの削除、受信ルールの追加／削除／変更などのログを提供 メール閲覧、検索のログを提供（「高度な監査」が使用できるライセンスでのみ利用可能） SessionIdを使いログインと操作のログを紐づけ 7 、攻撃者による メール閲覧履歴 や 転送ルールの作成 や削除されたスパムメール送信履歴の調査などに利用可能 主に次の3つの方法で閲覧、ダウンロード可能 Exchange 管理センター > (左下の) 従来のExchange 管理センター> コンプライアンス管理 > メールボックス監査ログのエクスポート、管理者監査ログのエクスポート Exchange Online Powershellを利用したダウンロード 8 , 9 APIを利用したダウンロード Exchange管理センターの監査ログ閲覧／ダウンロード画面 Exchange OnlineのMessage Trace ログ （メッセージ追跡ログ） メールの送受信ログを提供 攻撃者によるメール転送やスパム攻撃の踏み台有無の調査に利用可能 主に次の3つの方法で閲覧、ダウンロード可能 「Exchange管理センター」 -> メールフロー -> メッセージ追跡 Exchange Online Powershellを利用したダウンロード 10 APIを利用したダウンロード 11 Exchange管理センターから閲覧可能なMessage Traceログ ログ取得 推奨するログ取得方法や、実際の手順をコマンドレベルで説明します。 インシデント発生時の初動対応としてのログ保全や、平時に期限切れで消えてしまうログの定期的な保全などにお役立てください。 ただしログを記録しておくための設定をしておかないと、一部取得できないログがあります。設定方法については 後編 で説明するため、そちらも併せて参照することを推奨します。 Powershell vs 管理センター（ブラウザ）vs API ログを取得する手段としていくつかの方法が提供されていますが、NTT ComではPowershellコマンドレットでの取得を推奨しています。 Web の管理センター経由のログダウンロードでは一部のログの欠損が確認されています。その旨通知は出ずログの欠損に気付くことができないため、信頼できるログ取得の観点からは不向きと言えます。 一方でPowershellの場合、ログが欠損せず信頼性の点で優れています。さらにログ取得操作の自動化が容易で、そのため簡易的な操作で多くのログを扱えるログ取得ツールが有志により提供されています。以上の点でPowershellの使用を推奨します。 なお、APIも同様に信頼性と自動化の利点を持ち、ツールやシステムに組み込む際には有用です。しかし単に情報取得に使うには使用方法が複雑であるため、Powershell のほうが使いやすいと考えます。 注意点として、Powershellでたくさんのリクエストを送ると一定時間ロックされる可能性があるため、適切にリクエストレートを制限する必要があります。 ログ取得実施手順の概要 すべてのログをダウンロードすることが望ましいと言えますが、ログのダウンロード数上限やログサイズの観点から、ユーザ数の多い環境では一部のログのみダウンロードすることが現実解と言えます。 ここでは、NTT Comにおける調査に最低限必要なログをダウンロードする方法を紹介します。 なお、大規模テナントの場合、これらの方法でもダウンロード数上限に達し十分なログが取れない場合があります。大規模テナントをご利用されている場合は、SIEMの使用を推奨します。 ログの取得は次の流れで行います。 攻撃に関与したユーザを特定するため、サインインログを中心とした全ユーザに関するログ取得 1の解析により判明した攻撃に関与したユーザの詳細ログ取得 これらのログを取得するため、NTT Comでは次の2つのツールを利用します。これらの使い方について詳細に説明します。 HAWK 12 Office 365 Extractor 13 事前準備 各種ツールの日本語対応 HAWKやOffice 365 Extractorは現時点では日本語に完全対応はしていないためCSVに日本語が出力できません。これを回避するため Powershell console 上で次のコマンドを実行してから各種ツールを実行してください。 function Export-Csv(){ $input | Microsoft.PowerShell.Utility\Export-Csv @args -Encoding UTF8 } なお、一度 Poweshell console を閉じると、上記設定は無効化されます。Powershell console 起動の都度実行してください。 ExchangeOnlineManagement module のインストール Install-Module -Name ExchangeOnlineManagement 1. 全ユーザに関するログの取得 HAWKでのログ取得 次の通りにPowershellでコマンドを打ち、HAWKでログ取得します。 # HAWKのインストール > Install-Module -Name HAWK # HAWKを使う準備 > Import-Module HAWK # テナントの全ユーザについてログ取得 > Start-HawkTenantInvestigation 実行途中で指定したフォルダに、結果のファイルが出力されます。 Office 365 Extractorでのログ取得 Office 365 Extractorをダウンロードした後、スクリプトを実行します。 > .\Office365_Extractor.ps1 特定の種類のログを取得するため、3を入力します。 Following actions are supported by this script: 1 Show available log sources and amount of logging 2 Extract all audit logging 3 Extract group audit logging 4 Extract specific audit logging (advanced mode) 5 ReadMe 6 Quit Select an action: 3 取得したいログ種別としてAzureを選択するため、2を入力します。 1: Extract all Exchange logging 2: Extract all Azure logging 3: Extract all Sharepoint logging 4: Extract all Skype logging 5: Back to menu Select an action: 2 取得対象とするユーザとして全ユーザを指定するため、1を入力します。 Would you like to extract log events for [1]All users or [2]Specific users >: 1 Extracting the Unified Audit Log for all users... 取得期間を入力します。Enterキーだけを押すと本日から90日間前までが設定されます。 Please enter start date (format: yyyy-MM-dd) or ENTER for maximum 90 days: Please enter end date (format: yyyy-MM-dd) or ENTER for today: 取得間隔を分単位で入力します。 ログ取得に利用しているExchangeOnlinePowershellが一度に5,000件までしか取得できないため、細かく分割して取得することでその制限を回避するための設定です。 短くしすぎると、取得間隔を短くしてのリトライが発生して効率が落ちます。 ログが少ない環境では14400分（10日間）など長くすると早く終わります。 Recommended interval: 60 Lower the time interval for environments with a high log volume Please enter a time interval or ENTER for 60: 14400 この後、認証が求められますが、多要素認証を設定している場合は、最初に出る認証画面はキャンセルを押してください。次に別な認証画面が出るので、そちらでログインしてください。ログ取得が実行され、結果はファイルとしてカレントフォルダに出力されます。 2. 攻撃に関与した疑いのあるユーザのログ取得 全ユーザに関するログの分析により判明した（もしくはすでに明らかになっている）攻撃に関与した疑いのある特定ユーザごとに、より詳細なログを取得します。 可能であれば全ユーザに対して詳細なログを取得することが望ましいですが、ユーザ数が多い場合は現実的でないため、攻撃者の関与が疑われるメールアカウントに限定して取得しています。 HAWKでのログ取得 > Start-HawkUserInvestigation <ユーザのメールアドレス> Office 365 Extractorでのログ取得 スクリプトを実行します。 > .\Office365_Extractor.ps1 全種別のログを取得するため、2を入力します。 Following actions are supported by this script: 1 Show available log sources and amount of logging 2 Extract all audit logging 3 Extract group audit logging 4 Extract specific audit logging (advanced mode) 5 ReadMe 6 Quit Select an action: 2 取得対象として特定ユーザを指定するため、2を入力します。 Would you like to extract log events for [1]All users or [2]Specific users >:2 ログを取得したいユーザのメールアドレスをカンマ区切りで入力します。 Provide accounts that you wish to acquire, use comma separated values for multiple accounts, example (user1@example.com,user2@example.com) >: user1@example.com, user2@example.com これ以降の手順はテナントの全ユーザのログ取得時と同様です。 MessageTraceログの取得 最後に、攻撃者の関与が疑われる特定ユーザに関して、MessageTraceからメールの送受信ログを取得します。 本手順により最大で過去90日、50,000件のログが取得可能です。(過去10日以内の最大1,000件のデータで十分でしたら Get-MessageTrace コマンドレットを使用する方がより簡単です。) まずExchange Online Powershellに接続します。管理者権限のあるアカウントを使用してください。 > Import-Module ExchangeOnlineManagement > Connect-ExchangeOnline -UserPrincipalName <User Principal Name, メールアドレス等> ログ生成クエリを発行します。 (例では -SenderAddress で送信アドレスを指定しています。 -RecipientAddress を使えば受信アドレスを指定できます。) > Start-HistoricalSearch -ReportTitle "test" -StartDate 2019/12/1 -EndDate 2020/1/20 -ReportType MessageTrace -SenderAddress adminuser1@example.com JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test NotStarted 0 タスクの進行状況を確認します。 StatusがNotStartedになっているためまだ開始されていません。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test NotStarted 0 タスクの進行状況を確認します。 StatusがInProgressになっているため実行中です。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test InProgress 0 タスクの進行状況を確認します。 StatusがDoneになっているため実行完了しています。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test Done 2 JobIdを指定し詳細情報を確認します。下記のFileUrlに記載のURLに、ブラウザでアクセスしログをダウンロードできます。 > Get-HistoricalSearch -JobId 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX | Format-List (...略...) FileUrl : https://admin.protection.outlook.com/ExtendedReport/Download?Type=OnDemandReport&RequestID=7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX ReportStatusDescription : Complete – Ready for download ReportType : MessageTrace (...略...) まとめ 本記事では Microsoft Exchange Online 関係のログの概要と、ログ取得方法を説明しました。 どのようなログが取れるかを知っておくことは、いざというとき有効活用するために必要不可欠です。 その一助となるべく公開された本記事をご活用いただけると幸いです。 冒頭で述べたとおり、 後編 ではログを記録しておくための設定について説明します。よろしければそちらもご覧ください。 https://developer.ntt.com/ja/blog/b097ce00-8942-43c6-bad4-842087f8dc6b ↩ https://blogs.technet.microsoft.com/junichia/2015/10/28/office-365-azure-adintuneazure-rms/ ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-unifiedauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-sign-ins ↩ https://aad.portal.azure.com/ ↩ https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-powershell-reporting ↩ https://techcommunity.microsoft.com/t5/security-compliance-and-identity/contextualizing-attacker-activity-within-sessions-in-exchange/ba-p/308710 ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-mailboxauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-adminauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/get-messagetrace?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/previous-versions/office/developer/o365-enterprise-developers/jj984335(v=office.15) ↩ https://github.com/Canthv0/hawk ↩ https://github.com/PwC-IR/Office-365-Extractor ↩ *1 : 他にも複数のダウンロード方法が提供されています。詳しくはMicrosoft社にお問い合わせください。

はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 ( @Mahito ) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト ( The official YAML Web Site ) ではこう書かれています。 YAML is a human friendly data serialization standard for all programming languages. また、Wikipedia ( YAML - Wikipedia ) では初期の意味と現在の意味が違うと書いてありました。 YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語じゃない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。 現在の最新バージョンは 1.2 で 12 年近く更新されていません。 ( 最後のパッチは 2009-10-01 ) 表記方法 階層構造の表現 YAML はインデントを使い階層構造で内容を表現します。ただし、 インデントにはタブが使えずスペースのみが使えます 。（インデントはスペース 2 個単位ですることが多いそうです） 始まりと終わり YAML ドキュメントは 任意 で --- から開始して、 ... で終わらせることができます。 これは、YAML 形式の一部で、ドキュメントの最初と最後を示し、これらを用いることで 1 つのファイル内に複数の YAML ドキュメントを埋め込むことができます。 --- # やることリスト（ブロック形式） - ブログを書く - イベントの企画 - 技術調査・検証 ... --- # 買い物リスト（インライン形式） [ トマト, 卵, サラダ油 ] 1 つのドキュメント内に複数の YAML ドキュメントが埋め込まれている場合、プログラミング言語によっては load / safe_load では 1 つの YAML ドキュメントしか読めない、またはそもそも読み込みできないものがあります。 ( Ruby ) では複数のうち先頭の 1 つの YAML ドキュメントしか読めません。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .safe_load(yml) end # => ["ブログを書く", "イベントの企画", "技術調査・検証"] Python では yaml.composer.ComposerError: expected a single document in the stream が返されます。 import yaml with open ( 'sample.yml' ) as f: docs = yaml.safe_load(f) for doc in docs: print (doc) # => yaml.composer.ComposerError: expected a single document in the stream 1 つのドキュメント内に複数の YAML ドキュメントがあるファイル読み込む際は load_stream ( Ruby )や load_all ( Python ) を使うとまとめて読むことができます。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .load_stream(yml) end # => [["ブログを書く", "イベントの企画", "技術調査・検証"], ["トマト", "卵", "サラダ油"]] なお、 --- を "directives end"、 ... を "document end" と呼ぶそうですが、わかりにくいということで、 --- を YAML 1.1 で使われいた "document start" という名前に戻そうという RFC が上がっています。 私は --- が YAML に書かれているのを見たことがありますし、何なら使ってもいましたが、「YAML の先頭にある記号でなくても良い」程度にしか意識してきていませんでした。さらに、 ... はまったく見たことがなかったので、今回調べて初めて知りました。 コメント 行頭、もしくはスペースの後に番号記号 "#" を指定すると、その後はコメントになります。 # 行頭コメント [ トマト, 卵, サラダ油 ] # これもコメント リスト - を並べることでリスト表現が可能です。 --- # 果物一覧 - りんご - みかん - いちじく - もも 上記はブロック形式ですが、インデントを使わずにインライン形式で [..., ..., ] と表現することもできます。 --- # 果物一覧 [ りんご, みかん, いちじく, もも ] 連想配列 key: value とすることで連想配列の表現が可能です。 --- # 果物と色の組み合わせ一覧 りんご : 赤 みかん : オレンジ いちじく : 白と赤 もも : ピンク # => {"りんご" => "赤", "みかん" => "オレンジ", "いちじく" => "白と赤", "もも" => "ピンク"} リスト同様にインライン形式で {key1: value1, key2: value2, } と表現することもできます。 { りんご : 赤, みかん : オレンジ, いちじく : 白と赤, もも : ピンク } key:value と : の後ろにスペースを空けないと、文字として扱われてしまいます。 key:value # => "key:value" また、 : のあとのスペースもしくは改行はマッピングに利用されるので次のような c: という表現はエラーとなります。 windows_drive : c: # => (<unknown>): mapping values are not allowed in this context at line 1 column 17 (Psych::SyntaxError) マッピング以外の意図で : を利用する際は、 : の後ろにスペースや改行をいれない、もしくは '' や "" で括れば利用できます。 windows_path : c:\windows c_drive : 'c:' d_drive : "d:" # => {"windows_path"=>"c:\\windows", "c_drive"=>"c:", "d_drive"=>"d:"} "" ではエスケープを使用できる点が、 '' との違いです。 single quote : 'エスケープが使えません\n' double_quote : "エスケープが使えます \n " # => {"single quote"=>"エスケープが使えません\\n", "double_quote"=>"エスケープが使えます\n"} 複雑なキーマッピング YAML では "? " ( ? とスペース)を使うと複雑なキーを生成できます。 (出典) Example 2.11. Mapping between Sequences ? - Detroit Tigers - Chicago cubs : - 2001-07-23 # => {["Detroit Tigers", "Chicago cubs"]=>[#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>]} 上の ["Detroit Tigers", "Chicago cubs"] がキー、下の 2001-07-23 が Value となります。 同様に Key に連想配列も指定可能です。 ? { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {{"New York Yankees"=>"Atlanta Braves"}=>[#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>]} ちなみに "? " を外すと下の : 以下は無視されます。 { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {"New York Yankees"=>"Atlanta Braves"} ? を使うことで value を null にした連想配列の作成も可能です。 (出典) Example 2.25. Unordered Sets --- ? Mark McGwire ? Sammy Sosa ? Ken Griff # => {"Mark McGwire"=>nil, "Sammy Sosa"=>nil, "Ken Griff"=>nil} このあたりも YAML の公式ドキュメントを見て初めて知った機能です。 連想配列の key に配列や連想配列を利用したり、連想配列の value を null にするなど、今まで使ったことがない機能ですが知っておくといつの日にか使う機会が訪れるやもしれませんね。 Bool の扱い Bool型値 (True/False) は複数形式で指定可能です。 a : yes b : no c : True d : TRUE e : false # => {"a"=>true, "b"=>false, "c"=>true, "d"=>true, "e"=>false} 連想配列のキーに yes や true , no などを使うと想定しない動きをするので注意が必要です。 yes : "We can" # => {true=>"We can"} もし先頭を yes にする場合は文字として設定する必要があります。 "yes" : "We can" # => {"yes"=>"We can"} 複数行に分けた表現 文字列は、 | または > を使用して複数行に分けることができます。 | を使用して複数行に分けた場合には、改行と、末尾にあるスペースが含まれます。 pipe_lines : | 複数行の文章は '|' を使うことで 楽に書けます。　 # => {"pipe_lines"=>"複数行の文章は\n'|' を使うことで\n楽に書けます。　\n"} > を使うと改行を折り返してスペースに置き換えます。 long_text : > 長い文章は '>' を使うことで 1行で書けます # => {"long_text"=>"長い文章は '>'を使うことで 1行で書けます\n"} どちらの場合もインデントは無視されます。 > を使う場合で改行をしたいときは以下の2つを用いて改行できます。 改行だけの空白行 インデント後に値を記入 long_text_lines : > a b c d e f # => {"long_text_lines"=>"a b\nc d\n e\nf\n"} | や > の機能は知っていましたが、 > の改行で「インデント後に値を記入」は知らない機能でした。 この機能はインデントを含めた改行になるのでちょっと使い方が限られますが知っておくと便利な仕様ですね。 タグと型 YAML は型を明示していない場合、暗黙的な型付けがされます。明示的な型付けは ! のシンボルを使ったタグで示されます。 date : 2021-09-02 not-date : !!str 2021-09-02 # => { # "date"=>#<Date: 2021-09-02 ((2459460j,0s,0n),+0s,2299161j)>, # "not-date"=>"2021-09-02"} デフォルトのタグ URI は tag:yaml.org,2002: です。その中で定義されている型のタグは以下のとおりです。 Collection Types map omap pairs set seq Scalar Types binary bool float int merge (省略記法 << ) null str timestamp value yaml 参照 ： Language-Independent Types for YAML™ Version 1.1 タグの URI を明示的に切り替える場合は %TAG ! tag:hoge.com,2002: のように設定します。 上記のようにデフォルトで定義されているタグの呼び出しは !!str のようにエクスクラメーションマーク 2 つ ( !! ) , アプリケーション特有のローカルタグの呼び出しはエクスクラメーションマーク 1 つ ( ! ) と別れています。 例: omapを指定 --- !!omap - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => {"yesterday"=>"2021-09-01", "today"=>"2021-09-02", "tomorrow"=>"2021-09-03"} 例: omapなし --- - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 例: mapを指定 --- !!map - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 余談 1.10 など末尾に 0 が入る数字を明示的に表現するためには文字にする必要があります。 !!float 型では末尾の 0 が表示されないので注意が必要です。 --- - 1.10 - !!float 1.10 - '1.10' # => [1.1, 1.1, "1.10"] タグと型の機能も全く知らない機能でした。 型の機能は調べている中で便利だと感じたのでこれから使っていきたい機能です。 アンカーとエイリアス YAMLは & でアンカーを設定し、 * で参照が可能です。さらに << もしくは !!merge を使うことで、参照先の値の変更も可能です。 --- !!omap - default : &default user : root password : password db_url : localhost:3306 - development : *default - production : <<: *default db_url : production:3306 # => {"default"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "development"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "production"=>{"user"=>"root", "password"=>"password", "db_url"=>"production:3306"}} 上記の例では default というアンカーを設定し、development はそのまま参照、poroduction は db_url を変更をしています。 エイリアスとアンカーも見たことはあるけどうまく使えてなかった機能です。 今回調べたことで理解が深まったので今後は使っていきたいです。 YAMLの今後 ここまで紹介してきた現在のバージョンは "YAML 1.2 - 3rd Edition, Patched at 2009-10-01" です。 このバージョンは 12 年近く更新されていませんでしたが、今年の 5 月に突然次期バージョンへのRFCが始まっています。 YAML Spec RFCs GitHub 上で Template をベースに PR 形式で RFC を受け付けているので、興味があればリポジトリを覗いてみて、提案があれば RFC を書いてPRをしてみてはいかがでしょう。 まとめ 普段何気なく使っている YAML ですが、まだ知らない、うまく使えていない機能がありました。 この記事では YAML のすべてを紹介できてはいませんが、もしこの記事を読んで YAML に興味を持っていただけたのであれば、一度 YAML の公式ページ を読んでみることをおすすめします。 また、YAML の新しいバージョンが動き出しているので、そちらも興味があればチェックしてみてはいかがでしょう。 参考 YAML Ain’t Markup Language (YAML™) Version 1.2 YAML - Wikipedia (英語) YAML - Wikipedia (日本語) YAML 構文 - Ansible Document Language-Independent Types for YAML™ Version 1.1

はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 ( @Mahito ) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト ( The official YAML Web Site ) ではこう書かれています。 YAML is a human friendly data serialization standard for all programming languages. また、Wikipedia ( YAML - Wikipedia ) では初期の意味と現在の意味が違うと書いてありました。 YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語じゃない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。 現在の最新バージョンは 1.2 で 12 年近く更新されていません。 ( 最後のパッチは 2009-10-01 ) 表記方法 階層構造の表現 YAML はインデントを使い階層構造で内容を表現します。ただし、 インデントにはタブが使えずスペースのみが使えます 。（インデントはスペース 2 個単位ですることが多いそうです） 始まりと終わり YAML ドキュメントは 任意 で --- から開始して、 ... で終わらせることができます。 これは、YAML 形式の一部で、ドキュメントの最初と最後を示し、これらを用いることで 1 つのファイル内に複数の YAML ドキュメントを埋め込むことができます。 --- # やることリスト（ブロック形式） - ブログを書く - イベントの企画 - 技術調査・検証 ... --- # 買い物リスト（インライン形式） [ トマト, 卵, サラダ油 ] 1 つのドキュメント内に複数の YAML ドキュメントが埋め込まれている場合、プログラミング言語によっては load / safe_load では 1 つの YAML ドキュメントしか読めない、またはそもそも読み込みできないものがあります。 ( Ruby ) では複数のうち先頭の 1 つの YAML ドキュメントしか読めません。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .safe_load(yml) end # => ["ブログを書く", "イベントの企画", "技術調査・検証"] Python では yaml.composer.ComposerError: expected a single document in the stream が返されます。 import yaml with open ( 'sample.yml' ) as f: docs = yaml.safe_load(f) for doc in docs: print (doc) # => yaml.composer.ComposerError: expected a single document in the stream 1 つのドキュメント内に複数の YAML ドキュメントがあるファイル読み込む際は load_stream ( Ruby )や load_all ( Python ) を使うとまとめて読むことができます。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .load_stream(yml) end # => [["ブログを書く", "イベントの企画", "技術調査・検証"], ["トマト", "卵", "サラダ油"]] なお、 --- を "directives end"、 ... を "document end" と呼ぶそうですが、わかりにくいということで、 --- を YAML 1.1 で使われいた "document start" という名前に戻そうという RFC が上がっています。 私は --- が YAML に書かれているのを見たことがありますし、何なら使ってもいましたが、「YAML の先頭にある記号でなくても良い」程度にしか意識してきていませんでした。さらに、 ... はまったく見たことがなかったので、今回調べて初めて知りました。 コメント 行頭、もしくはスペースの後に番号記号 "#" を指定すると、その後はコメントになります。 # 行頭コメント [ トマト, 卵, サラダ油 ] # これもコメント リスト - を並べることでリスト表現が可能です。 --- # 果物一覧 - りんご - みかん - いちじく - もも 上記はブロック形式ですが、インデントを使わずにインライン形式で [..., ..., ] と表現することもできます。 --- # 果物一覧 [ りんご, みかん, いちじく, もも ] 連想配列 key: value とすることで連想配列の表現が可能です。 --- # 果物と色の組み合わせ一覧 りんご : 赤 みかん : オレンジ いちじく : 白と赤 もも : ピンク # => {"りんご" => "赤", "みかん" => "オレンジ", "いちじく" => "白と赤", "もも" => "ピンク"} リスト同様にインライン形式で {key1: value1, key2: value2, } と表現することもできます。 { りんご : 赤, みかん : オレンジ, いちじく : 白と赤, もも : ピンク } key:value と : の後ろにスペースを空けないと、文字として扱われてしまいます。 key:value # => "key:value" また、 : のあとのスペースもしくは改行はマッピングに利用されるので次のような c: という表現はエラーとなります。 windows_drive : c: # => (<unknown>): mapping values are not allowed in this context at line 1 column 17 (Psych::SyntaxError) マッピング以外の意図で : を利用する際は、 : の後ろにスペースや改行をいれない、もしくは '' や "" で括れば利用できます。 windows_path : c:\windows c_drive : 'c:' d_drive : "d:" # => {"windows_path"=>"c:\\windows", "c_drive"=>"c:", "d_drive"=>"d:"} "" ではエスケープを使用できる点が、 '' との違いです。 single quote : 'エスケープが使えません\n' double_quote : "エスケープが使えます \n " # => {"single quote"=>"エスケープが使えません\\n", "double_quote"=>"エスケープが使えます\n"} 複雑なキーマッピング YAML では "? " ( ? とスペース)を使うと複雑なキーを生成できます。 (出典) Example 2.11. Mapping between Sequences ? - Detroit Tigers - Chicago cubs : - 2001-07-23 # => {["Detroit Tigers", "Chicago cubs"]=>[#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>]} 上の ["Detroit Tigers", "Chicago cubs"] がキー、下の 2001-07-23 が Value となります。 同様に Key に連想配列も指定可能です。 ? { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {{"New York Yankees"=>"Atlanta Braves"}=>[#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>]} ちなみに "? " を外すと下の : 以下は無視されます。 { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {"New York Yankees"=>"Atlanta Braves"} ? を使うことで value を null にした連想配列の作成も可能です。 (出典) Example 2.25. Unordered Sets --- ? Mark McGwire ? Sammy Sosa ? Ken Griff # => {"Mark McGwire"=>nil, "Sammy Sosa"=>nil, "Ken Griff"=>nil} このあたりも YAML の公式ドキュメントを見て初めて知った機能です。 連想配列の key に配列や連想配列を利用したり、連想配列の value を null にするなど、今まで使ったことがない機能ですが知っておくといつの日にか使う機会が訪れるやもしれませんね。 Bool の扱い Bool型値 (True/False) は複数形式で指定可能です。 a : yes b : no c : True d : TRUE e : false # => {"a"=>true, "b"=>false, "c"=>true, "d"=>true, "e"=>false} 連想配列のキーに yes や true , no などを使うと想定しない動きをするので注意が必要です。 yes : "We can" # => {true=>"We can"} もし先頭を yes にする場合は文字として設定する必要があります。 "yes" : "We can" # => {"yes"=>"We can"} 複数行に分けた表現 文字列は、 | または > を使用して複数行に分けることができます。 | を使用して複数行に分けた場合には、改行と、末尾にあるスペースが含まれます。 pipe_lines : | 複数行の文章は '|' を使うことで 楽に書けます。　 # => {"pipe_lines"=>"複数行の文章は\n'|' を使うことで\n楽に書けます。　\n"} > を使うと改行を折り返してスペースに置き換えます。 long_text : > 長い文章は '>' を使うことで 1行で書けます # => {"long_text"=>"長い文章は '>'を使うことで 1行で書けます\n"} どちらの場合もインデントは無視されます。 > を使う場合で改行をしたいときは以下の2つを用いて改行できます。 改行だけの空白行 インデント後に値を記入 long_text_lines : > a b c d e f # => {"long_text_lines"=>"a b\nc d\n e\nf\n"} | や > の機能は知っていましたが、 > の改行で「インデント後に値を記入」は知らない機能でした。 この機能はインデントを含めた改行になるのでちょっと使い方が限られますが知っておくと便利な仕様ですね。 タグと型 YAML は型を明示していない場合、暗黙的な型付けがされます。明示的な型付けは ! のシンボルを使ったタグで示されます。 date : 2021-09-02 not-date : !!str 2021-09-02 # => { # "date"=>#<Date: 2021-09-02 ((2459460j,0s,0n),+0s,2299161j)>, # "not-date"=>"2021-09-02"} デフォルトのタグ URI は tag:yaml.org,2002: です。その中で定義されている型のタグは以下のとおりです。 Collection Types map omap pairs set seq Scalar Types binary bool float int merge (省略記法 << ) null str timestamp value yaml 参照 ： Language-Independent Types for YAML™ Version 1.1 タグの URI を明示的に切り替える場合は %TAG ! tag:hoge.com,2002: のように設定します。 上記のようにデフォルトで定義されているタグの呼び出しは !!str のようにエクスクラメーションマーク 2 つ ( !! ) , アプリケーション特有のローカルタグの呼び出しはエクスクラメーションマーク 1 つ ( ! ) と別れています。 例: omapを指定 --- !!omap - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => {"yesterday"=>"2021-09-01", "today"=>"2021-09-02", "tomorrow"=>"2021-09-03"} 例: omapなし --- - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 例: mapを指定 --- !!map - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 余談 1.10 など末尾に 0 が入る数字を明示的に表現するためには文字にする必要があります。 !!float 型では末尾の 0 が表示されないので注意が必要です。 --- - 1.10 - !!float 1.10 - '1.10' # => [1.1, 1.1, "1.10"] タグと型の機能も全く知らない機能でした。 型の機能は調べている中で便利だと感じたのでこれから使っていきたい機能です。 アンカーとエイリアス YAMLは & でアンカーを設定し、 * で参照が可能です。さらに << もしくは !!merge を使うことで、参照先の値の変更も可能です。 --- !!omap - default : &default user : root password : password db_url : localhost:3306 - development : *default - production : <<: *default db_url : production:3306 # => {"default"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "development"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "production"=>{"user"=>"root", "password"=>"password", "db_url"=>"production:3306"}} 上記の例では default というアンカーを設定し、development はそのまま参照、poroduction は db_url を変更をしています。 エイリアスとアンカーも見たことはあるけどうまく使えてなかった機能です。 今回調べたことで理解が深まったので今後は使っていきたいです。 YAMLの今後 ここまで紹介してきた現在のバージョンは "YAML 1.2 - 3rd Edition, Patched at 2009-10-01" です。 このバージョンは 12 年近く更新されていませんでしたが、今年の 5 月に突然次期バージョンへのRFCが始まっています。 YAML Spec RFCs GitHub 上で Template をベースに PR 形式で RFC を受け付けているので、興味があればリポジトリを覗いてみて、提案があれば RFC を書いてPRをしてみてはいかがでしょう。 まとめ 普段何気なく使っている YAML ですが、まだ知らない、うまく使えていない機能がありました。 この記事では YAML のすべてを紹介できてはいませんが、もしこの記事を読んで YAML に興味を持っていただけたのであれば、一度 YAML の公式ページ を読んでみることをおすすめします。 また、YAML の新しいバージョンが動き出しているので、そちらも興味があればチェックしてみてはいかがでしょう。 参考 YAML Ain’t Markup Language (YAML™) Version 1.2 YAML - Wikipedia (英語) YAML - Wikipedia (日本語) YAML 構文 - Ansible Document Language-Independent Types for YAML™ Version 1.1

こんにちは、イノベーションセンターの三島です。 本記事では、次世代の監視技術として期待されるTelemetry技術についてご紹介します。 この記事について 本記事では下記の3点を共有します。 従来の監視技術が抱える課題とTelemetryの可能性 Telemetryの技術概要と、各社の実装状況 NTT Comのネットワーク上で検証し得られた知見と、期待されるユースケース 従来の監視技術が抱える課題 ネットワーク運用においては、障害検知やパフォーマンス分析のため監視技術が重要となります。 従来のネットワークでは、SNMP（Simple Network Management Protocol）と呼ばれる技術が広く利用されています。 SNMPの仕組みを図1に示します。SNMPはUDPベースなネットワーク監視技術です。データモデルはMIB（Management Information Base）と呼ばれるデータベースに定義されており、ベンダ共通の標準MIBと固有の拡張MIBが存在します。 SNMPの情報取得者をSNMP Manager、情報発行者をSNMP Agentと呼びます。情報の取得手法として、SNMP Managerがリクエストベースに情報を取得するPollingと、SNMP Agentがトリガーベースに情報を送信するTrapが存在します。 従来のSNMPが抱える課題として、下記の3点が挙げられます。 高負荷な処理構造 マルチベンダ環境における管理の煩雑さ N対N構成での規模性の限界 1.高負荷な処理構造について図2に示します。 ネットワーク監視ではトラフィック量や機器の負荷情報（Memory・CPU・温度等）の取得が求められます。しかしSNMPのPollingはリクエストベースであるため、高精細な情報を取得するために間隔を狭めると、CPU負荷の増大と処理時間の増加が課題となります。 2.マルチベンダ環境における管理の煩雑さについて図3に示します。 SNMPでは標準MIBが乏しく、例えばCPU使用率等のパラメータを取得できない課題が存在します。 そのため、マルチベンダな環境で同じ情報を取得するためには、機種ごとに固有な拡張MIBのOID（Object ID）を指定する必要があり、管理コストが増大します。 3.N対N構成での規模性の限界について図4に示します。 大規模なネットワークでは、データ利活用のため複数のデータ利用者が同じ機器の情報を取得することが考えられます。（例えば利用者Aはトラフィック量を可視化のために取得し、利用者Bはインターフェース状態をDown検知のために取得するなど） SNMPではAgentとManagerを1対1のUDPで接続して監視するため、N対N構成ではAgent/Managerの組み合わせ分のUDP接続が必要となり、受信側で処理可能なメッセージに限界が生じます。 また、送信先・監視先ごとに異なる値を取得したい場合、組み合わせに応じてSNMP Agent/Managerに定義する必要があり、管理コストが増大します。 まとめとして、SNMPは下記3種の課題を抱えています。 高負荷なプロトコル構造による取得可能な情報精度の低下と、リアルタイム性の損失 標準MIBの乏しさによるマルチベンダ環境における管理の煩雑さ N対N構成構築時の規模性の課題 これらを解決する監視技術として、Telemetry技術が期待されています。 Telemetryについて Telemetryは次世代のネットワーク監視技術であり、各社による検討や実装・OpenConfig等による標準化が進められています。 Telemetryは、一般的には下記3つの特徴を持つよう設計されています。 SNMPと比較し低負荷なプロトコル設計による高精細でリアルタイムな情報取得 OpenConfigによるベンダフリーな情報取得 Pub/Subモデルの導入が容易な設計による高い規模性 これらの特徴から、前節で挙げたSNMPの課題を解決する技術として期待されています。 Telemetryは、Pub/Subモデルと呼ばれるデータの送受信モデルを採用しています。 Pub/Subモデルについて図5に示します。 Pub/Subモデルは下記3つの要素から構成されます。 Publisher: 発行者 (送信者)。メッセージを発行する Broker: 仲介者。メッセージを仲介する Subscriber: 購読者 (受信者)。メッセージを取得し活用する Pub/Subモデルの利点として、① メッセージの送信者・受信者がお互いを直接認識する必要がなく、非同期かつ疎結合である点、②Brokerを介して1対N、N対N構成が取れるため、規模性の高い点 が挙げられます。情報はTopicという属性で管理され、Publisher・SubscriberはTopicを指定することにより情報を送信・受信します。 図6にTelemetryのパイプライン構成を示します。 Telemetryパイプラインは下記の要素から構成されます。 Publisher: データの発行元であるネットワーク機器 Broker: Pub/Subの多重化を行う仲介役 Subscriber: データの受け取り・利用をするアプリケーション Pub/Subモデルの利点は失われますが、上記の構成以外にPublisherとSubscriberを直結する構成も可能です。 以降でそれぞれの要素について解説します。 Publisher Publisherはメッセージの発行者であり、下記の3つの要素から構成されます。 監視対象となるネットワーク機器 監視対象機器とCollectorを繋ぐTransport部分 Publisherからデータを受信するCollector 監視対象機器に関する概念として、情報モデルと接続方式の分類についてご説明します。 機器の情報モデルには、主にOpenConfig・ベンダネイティブの2種が存在します。OpenConfigはベンダニュートラルな利用を想定して標準化が進められているネットワークコンフィグのモデルであり、YANGに従い定義されています。一方ベンダネイティブは製品ごとに固有の情報モデルであり、一般的にOpenConfigよりも対応状況が良く、扱うことのできる情報も豊富な傾向があります。 機器が発行する情報は、Sensor-Pathと呼ばれるデータパスにより予め指定されており、決められた間隔でメッセージを発行し、Collectorへと送信します。 下記にSenrsor-Pathの例を示します。Sensor-PathはYANGのツリー構造に合わせて情報を取得するためのデータパスであり、SNMPにおけるOIDに近い概念です。 OpenConfig: Interfaceに関する情報全般（Configuration/State/Statistic含む） “/interfaces/” OpenConfig: Interfaceごとの入力パケットカウンタ（単位: byte） “/interfaces/interface/state/counters/in-octets” OpenConfig: xe-0/0/0の入力パケットカウンタ（単位: byte） “/interfaces/interface[name='xe-0/0/0']/state/counters/in-octets” Juniper ベンダネイティブ: Interfaceに関する情報全般 “/junos/system/linecard/interface/” 例のように、深いパスを指定することで取得する情報を細かく指定できます。 また、OpenConfigとベンダネイティブでは同じ情報を取得する場合でも異なるパスを指定する必要があります。 2021年8月時点の実装では、同じOpenConfigでもベンダにより対応状況が異なるため、各社のドキュメントを確認し取得するSensor-Pathを決める必要があります。 次に接続方式の違いについてご説明します。Telemetryでは、情報を発行するPublisherと受け取るCollectorの接続方向により、Dial-InとDial-Outの接続方式が存在します。図7にそれぞれぞれの概念を示します。 Dial-InはCollectorがPublisherに接続する手法です。利点としてはgRPCによる自動化を行っているネットワークの場合、機器に設定されたgNMIを利用して情報を取得できるため、Telemetry用追加設定の不要な点が挙げられます。 一方Dial-OutはPublisherがCollectorに接続する手法です。利点としてはCollector側が監視するPublisherのリストを管理する必要がないためCollectorをステートレスに設計可能であり、Dial-Inに比べて規模性が高い点や、Publisher側にもACLによる制御が不要となる点が挙げられます。 上記より、特別な理由がない場合は管理コストを考慮しDial-Outを採用することをお勧めします。ただし、例えばgRPCによる運用自動化を行っているネットワークなどでは、Dial-InのTelemetryが容易に導入可能な場合もあります。また、2021年8月時点では、ベンダによりDial-In/Dial-Outの対応状況が異なるため、注意が必要です。 次にTransport部分について説明します。Transportは監視対象デバイスとCollectorを繋ぐ転送の役割を持ちます。 TransportはEncodingとEncapsulationの要素から成り立ちます。 Encoding: メッセージの形式。JSON、GPBなどから選択可能 Encapsulation: 通信形式。TCP/UDPやgRPC、NETCONFなどを選択可能 SNMPはUDPによる通信のみを採用していましたが、Telemetryではメッセージをどのような形式で記述し、どのような通信形式で送るかを決めることができます。取得したい情報の性質や、運用で既に採用しているプロトコルなどを考慮しながら決めることをお勧めします。 CollectorはPublisherが発行したメッセージを受信する役割を持ちます。2021年8月時点の主なCollector実装を下記の表にご紹介します。 ベンダ OSS実装 ベンダ純正実装 ※Subscriber機能も兼ねる Arista ockafka Openconfigbeat Arista CloudVision Cisco Pipeline Telegraf/Fluentd等の専用Plugin Crosswork Health Insights Juniper Jtimon Telegraf/Fluentd等の専用Plugin Paragon Insights SONiC gnxi（単発で取得するCLIツール） gNMIc - 上記でご紹介したベンダ純正実装は、単体のCollectorではなくSubscriberとしての可視化や自動化の機能を備えています。 Collectorごとに特徴や存在する機能が異なるため、例えばPublisherのグループ化やKafkaとの連携など、必要な機能を考慮し選定することをお勧めします。 Broker Brokerはメッセージの仲介者であり、Message Queueが該当します。 Message Queueはメッセージを中継する要素であり、主な実装としてはApache Kafkaや、Public CloudにおけるCloud Pub/Sub・SQSなどが挙げられます。 一般的な実装では、クラスタリングやミラーリングなど、冗長化を行う仕組みを持つことが多いです。図8に一般的なBrokerのMessage Queue的な役割を示します。 Publisherが発行するメッセージにはTopicとデータが含まれています。Brokerは受信したメッセージをTopicごとのキューに格納した後、Subscriberからの購読に応じてメッセージを送信します。 Subscriber Subscriberはメッセージの受信者であり、データを受け取り利用する要素です。 Subscriberはユースケースごとに様々な機能・パイプラインを持ちます。一般的には①リアルタイムな監視 & 詳細な情報に基づく可視化・分析、②アラート、③設定の自動化/自己治癒 などが考えられます。 検証構成と取得結果 ここからは、NTT Com内にて実施した検証についてご紹介します。 今回の構成では、NTT Comの社内ネットワーク環境において検証を実施しました。図9に構成図の一部を示します。 検証ではPublisher/Subscriberをそれぞれ多重化し、Brokerに収容しています。 監視対象の機器はArista・Cisco・Juniperと、Whiteboxな伝送装置に搭載されたSONiCの4ベンダを採用しています。また、SubscriberはオンプレミスのGrafanaによる可視化を行うと同時に、Google Cloud Platform上のKafkaにミラーリングを行い、Public Cloudと連携が行えることも検証しました。 図10、図11にそれぞれから取得した実際のデータをJSON形式で示します。 図10はArista機器で発行し、ockafkaを通じ取得したデータの例です。図の通り、データは単発のJSON型となっています。 一方、図11はその他の機器から取得したデータの例です。図の通り、Juniper/TelegrafではネストされたJSON型になっており、SONiC、gNMIcはJSON型の中にリストが含まれています。また、Cisco/Pipelineでは複数のJSON型がリストに含まれる形式であることがわかります。 このようなデータは直接InfluxDBに取り込むことができないため、整形処理が必要となります。LogstashやTelegrafといったコレクタには整形機能が存在しますが、デバッグが難しい、複雑な条件分岐を書きにくいなど、汎用性に問題がありました。 そこで、今回の検証ではデータ整形機を作成し対応しました。図12にデータ整形機を含めたフローを示します。 作成したデータ整形機は、まずKafkaから生データが含まれるTopicを購読し、データを取得します。取得したデータをPython Scriptで整形した後、Kafkaに対して取得したものとは異なるTopicでメッセージを発行します。これにより、Subscriberがデータ整形機の発行したTopicを指定することで、整形後のデータを取得できるようにしています。 図13に、実際に取得したデータをGrafanaで可視化した例を示します。 今回の検証では、TelemetryとSNMPで、Interfaceの受信したTraffic量の可視化を行いました。Telemetryは1000ms（Junosのみ2000ms）、SNMPでは負荷を考慮し、一般的に1分以上の間隔で取得することが多いですが、今回はPrometheusが取得可能であった15秒間隔でデータを採り、比較しています。 図13ではマイクロバーストの検知を想定しバーストトラフィックを生成しております。結果の通り、Telemetryではリアルタイムで複数のスパイクが観測されますが、SNMPでは、Pollingによる遅延が入った後、なだらかな山となり可視化が行われていることが読み取れます。 検証を通じて得られた知見 ここからはNTT Com内での検証を通じて得られた知見と期待されるユースケースをご紹介します。 導入時に考慮すべき点として、下記3点が挙げられます。 1. 対象機種ごとにパラメータを分ける手法の検討 現時点のTelemetryでは、ベンダごとに①Collector、②Dial-In / Dial-Out、③OpenConfig/ベンダネイティブの選択を含めたSensor-Path などのパラメータを指定する必要があります。 マルチベンダ環境における効率的な管理のため、例えばNetbox・Zabbix等でデバイス情報を管理しているネットワークでは、それらの情報と組み合わせ、ベンダごとに設定を切り替える仕組みを開発することで、管理コストを下げることが期待できます。 2. データの保持期間と粒度 Telemetryはms単位での情報取得が可能であるため、取得した大量のデータを長期にわたって保持することが現実的ではありません。 そのため、Telemetry導入の際にはデータの保持期間や保持する時間的な粒度などの事前検討が必要となります。 これらに該当するユースケースは主に ① 取得した瞬間の閾値による処理（その瞬間の詳細なデータが必要）、② 障害発生後の切り分け（1日-2日以内の詳細なデータが必要）の2種が想定されます。①、②どちらのユースケースでも、詳細なデータは1日-2日のみ保持し、それを過ぎたものはデータを時間単位などで集約して保持すれば良いと考えます。 3. 監視基盤の性能 2.の内容とも関連しますが、Telemetryを導入する際にはネットワーク規模と取得データと量・保持期間に従い、事前に監視基盤のメモリやストレージ等のリソースを計算しておく必要があり、導入前の検証が必須となります。 Telemetryに期待されるユースケース これまでの結果より、現時点のユースケースとして下記の3点を考えています。 シングルベンダ環境におけるリアルタイムな情報収集 gNMIを通じたコンフィグ投入等、自動化技術との組み合わせ 他の監視技術との連携 1.については、OpenConfigでの実装が追いついていない部分もベンダネイティブなSensor-Pathにより情報を取得でき、またベンダごとの独自機能や純正Collectorの利用が可能です。さらに、ベンダ固有の実装（Cisco Event Driven TelemetryやMellanox What Just Happened等）を利用できるなどの利点が存在します。 2.については、共有のgNMIを利用して監視・自動化が可能である利点を生かし、Telemetryにより振る舞いを監視し、閾値や機械学習ベースでのコンフィグ変更・自己治癒などの利用が考えられます。 3.については、例えばTelemetryのStatisticをxFlowのリアルタイムなフローと組み合わせ利用する、SyslogアラートをトリガーとしTelemetryのState・Statisticを保存するなど、高精細な情報を生かす手法が考えられます。 またどの用途についても、今後OpenConfig対応の充実やCollector・Dial-Out対応などの統一により、マルチベンダ対応が進むことにより、より利用しやすい技術となると期待しています。 まとめ NTT Comでの技術検証を通じ、Telemetryの下記3点の特徴を検証しました。 SNMPと比較し低負荷な設計によるリアルタイムな情報取得 OpenConfigによるベンダフリーな情報取得 Pub/Subモデルの導入が容易な設計による高い規模性 2021年8月時点の実装では、リアルタイムな情報取得はms単位での情報取得・低負荷なプロトコル設計等により期待通りの強みがありますが、マルチベンダ性に課題があるというのが検証から得られた所感です。 OpenConfigの対応状況やCollectorの統一については、これからますます実装が進むと予想されるため、今後の発展に期待しています。 付録 今回の検証で用いた各機器のコンフィグ例を共有します。お手元での検証にご利用ください。 なお、これらコンフィグ例は現状有姿で提供され、NTT Comは明示的・黙示的を問わず一切の保証をせず、何ら責任を負いません。 Arista 本体側はgNMI設定か専用デーモンを立ち上げるかの2択。 EOS 4.22以降ではgNMI設定が推奨されている。 本体側 - gNMI設定 management api gnmi transport grpc Telemetry port <Port> ip access-group <ACL名> provider eos-native ! 本体側 - 専用デーモン設定 ※ OpenConfigの場合はTerminAttrをOpenConfigに読みかえる。 daemon TerminAttr exec /usr/bin/TerminAttr -disableaaa -grpcaddr <CollectorのIP addr>:<Port> ip access-group <ACL名> no shutdown ! Collector - ockafaka（Dockerでの立ち上げ例） 手順は 公式リポジトリ を参照。 $ docker pull aristanetworks/ockafka $ docker run aristanetworks/ockafka -addrs <Publisher Addr>:<Port> -kafkaaddrs <Kafka Addr>:<Port> -kafkatopic arista_eos_telemetry -subscribe <PATH> Collector - openconfigbeat（Dockerでの立ち上げ例） 手順は 公式リポジトリ を参照。 % git clone https://github.com/aristanetworks/openconfigbeat.git // openconfigbeat.ymlを編集 openconfigbeat: addresses: ["<Publisher Addr>"] default_port: <Port> paths: ["interfaces/interface/name"] username: "<Username>" password: "<Password>" output.kafka: hosts: ["<Kafka Addr>:<Port>"] topic: <Topic名> // openconfigbeat.ymlを/直下に配置するようDockerfileを編集 % docker build -f ./Dockerfile -t openconfigbeat:latest . --no-cache=true % docker run -d --net=host --name openconfigbeat openconfigbeat:latest Cisco IOS-XR 本体側 - Dial-Out設定 telemetry model-driven destination-group <destination-group名> vrf <VRF名> address-family ipv4 <Collector Addr> port <Port> encoding <エンコーディング手法> protocol <トランスポートのプロトコル> ! ! sensor-group <sensor-group名> sensor-path <sensor-path> ! subscription <subscription名> sensor-group-id <sensor-group名> sample-interval <Interval(ms)> destination-id <destination-group名> source-interface <インターフェース名> ! ! 本体側 - TPA（Third Party Applications）設定 IOS-XR標準のマネジメントVRF以外でTelemetryを扱う場合に必要。 vrf <VRF名> address-family ipv4 update-source dataports active-management ! ! ! Collector - Pipeline 手順は 公式リポジトリ を参照。 pipeline.confを編集後、 $ docker run -d --net=host [--volume <local>:/data] --name pipeline pipeline:<version> [collector] stage = xport_input type = grpc encap = gpbkv listen = :<Port> [kafka] stage = xport_output type = kafka encoding = json_events brokers = <Kafka Addr>:<Port> topic = <Topic名> [inspector] stage = xport_output type = tap file = /data/dump.txt datachanneldepth = 1000 Juniper 本体側 - Dial-In設定 set system services extension-service request-response grpc clear-text address <Publisher Addr> set system services extension-service request-response grpc clear-text port <Port> set system services extension-service request-response grpc skip-authentication set system services extension-service notification allow-clients address <Collector Addr> Junos 20.2R1以降でDial-Outにも対応している が、対応するOSSのCollector実装が存在しないため未検証。 Collector - Telegraf Juniper公式のCollector実装である jtimon も存在するが、Kafkaとの連携機能が存在しないため本検証ではTelegrafのモジュールを採用。 [[inputs.jti_openconfig_telemetry]] servers = ["<Publisher Addr>:<Port>", "<Publisher Addr>:<Port>"] # 取得対象を複数指定可 username = "<Username>" password = "<Password>" client_id = "telegraf" # 取得対象の機器内(ルータ等)でユニークである必要がある # 1つの機器に対して複数プロセスからsubscribeする場合は、 # 異なる文字列にする sample_frequency = "2000ms" sensors = [ "/interfaces/interface[name=vme]/state", "/system", "/components", "/junos" ] retry_delay = "1000ms" str_as_tags = false [[outputs.kafka]] brokers = ["<Kafka Addr>:<Port>"] topic = "<Topic名>" data_format = "json" SONiC 本体側 - Telemetryサービスの設定 # vi telemetry-service.yaml apiVersion: v1 kind: Service metadata: name: telemetry-svc spec: type: NodePort ports: - port: <Port> protocol: TCP selector: app: usonic # kubectl apply -f telemetry-service.yaml kubectl get svc を実行し、待ち受けポートを確認しておく。 Collector - gNMIc 手順は 公式ページ 参照。 # vi gnmic.yml targets: <Publisher Addr>:<Port>: subscriptions: - port_stats skip-verify: true username: <Username> password: <Password> insecure: true subscriptions: port_stats: target: COUNTERS_DB paths: - <Sensor-Path> mode: stream stream-mode: sample sample-interval: 5s encoding: json outputs: output1: type: kafka address: <Kafka Addr>:<Port> topic: <Topic名> format: json debug: true

はじめに IoT Connect Gatewayとは？ IoT Connect Gatewayの特徴 閉域網がなくてもセキュアにクラウド接続を実現 処理負荷がかかる暗号化処理をサービス側で実施 暗号化通信によるデータ転送量を抑制 クラウドアダプタ機能で各種クラウドサービスに簡単接続 IoT Connect Gatewayにかける思い CI/CDの取り組みとサービスリリース Infrastructure as Code Test as Code GitOps 個人的な思い 最後に 次回予告 ICGWに関するお問い合わせ先 はじめに こんにちは、データプラットフォームサービス部でIoT Connect Gateway開発チームのTech Leadを している 栗原良尚(@yoshinao) です。 この度、NTT Com Engineers' Blogオープンに合わせて、開発をおこなっているIoT Connect Gatewayについてご紹介、情報発信をできる機会をいただきました。閲覧頂きありがとうございます。 Engineers' Blogでは、単なるサービス紹介だけでなく、IoT Connect Gatewayの使い方や、どんな事ができるのか？などのレシピや周辺技術を実験や電子工作を通じて発信していきたいと思っております。 また、皆様からのリクエストやフィードバックを通じて、双方向の情報発信、みなさまの声を次期開発に活かしたいと考えておりますのでリクエストやコメントを頂けますと幸いです。個人的にも記事投稿の励みになります（笑） どうぞ、よろしくお願い致します。 IoT Connect Gatewayとは？ IoT Connect Gateway（ICGW） とは、NTT Comが 2021年4月6日にリリース したIoT向けGatewayサービスです。 このサービスは、IoTセンサーやデバイスで収集したデータをクラウドやお客様のサービスに簡単かつセキュアに転送するためのゲートウェイサービスです。 ICGWでは、IoTデバイスからの通信をNTT ComのGatewayで一度終端することで、IoTデバイス側に必要な機能をオフロードしたり、転送先を切り替えたり、デバイス側に機能追加必要なく様々な付加価値を利用することが可能になります。 ICGWは、NTT Comが提供している SmartDataPlatforｍ(SDPF) のIoTカテゴリのサービスで、 IoT Connect Mobile Type S と組み合わせてご利用が可能です。 今後も他のSDPFサービスのシームレスな連携を目指すことで、一つのプラットフォーム上でシームレスに融合、データを整理して利活用を容易にすることを目指しています。 IoT Connect Gatewayの特徴 以下に、現在のサービスの特徴をご紹介します。 1. 閉域網がなくてもセキュアにクラウド接続を実現 IoTデバイスからクラウドにセキュアにデータを送信したい場合、個別に閉域網で接続する、デバイスからデータ暗号化して送信するといった方法がありますが、どちらもコストがかかるという課題があります。 ICGWは、モバイル網とインターネットの境界に位置し、IoTデバイスからICGWの区間はモバイル網でセキュアに、ICGWからクラウドサービスに接続する時は、ICGWで暗号化(HTTPS/MQTTS) することでセキュアで安価なサービス接続を実現しています。 2. 処理負荷がかかる暗号化処理をサービス側で実施 IoTデバイスから暗号化したデータを送信する場合、デバイス側で暗号化を行うことになりますが、いくつかの課題に直面することがあります。 暗号化によってIoTデバイスの消費電力が大きくなってしまう IoTデバイスの製造コストが高くなってしまう ICGWは、これらの課題をサービス側で暗号化を行うことで解決します。端末側で暗号化の暗号化能力を気にする必要はありません。 また、鍵の交換などの作業もサービス側で一括して実施できるので、端末ごとの個別設定は必要なくなるというメリットがあります。 3. 暗号化通信によるデータ転送量を抑制 IoTデバイスから暗号化通信を行う場合、暗号化によるプロトコルオーバヘッドが発生し、暗号化しない通信と比較してデータ通信料が多くなるという課題があります。 ICGWでは、IoTデバイスからICGW区間は、閉域のモバイル網を利用するため、暗号化を必要とせずセキュアにデータを転送可能です。また、サービス側で暗号化処理を行うため、セキュアかつデータ通信量を節約することが可能です。 4. クラウドアダプタ機能で各種クラウドサービスに簡単接続 ICGWでは、暗号化と合わせて、各種クラウドサービスの差異を 意識することなく簡単に接続できるクラウドアダプタを提供しています。 この機能によって、IoTデバイスに利用クラウドに合わせた接続パラメータなどの個別の設定や開発のコストを削減することが可能となります。 各種クラウドサービスは、頻繁に機能アップデートや新規サービスを展開していますが、既に展開済みのIoTデバイスに、これらのアップデートを追従していくことは困難です。 しかしICGWを利用している場合、簡単に転送先サービスの変更や新機能が利用可能になります。 これはすでに展開済みのIoTデバイスを管理する上でも大きなメリットとなります。また、長期運用の観点では、暗号化プロトコルのアップデートや追従ができる点も重要になります。 現在対応中のクラウドサービス クラウドサービス プロトコル AWS IoTCore HTTP MQTT GCP IoTCore HTTP MQTT Azure IoTHub HTTP MQTT 現在、NTT ComのIoTプラットフォームである Things Cloud のクラウドアダプタやその他の新アダプタ対応についても現在開発を行っていますので、ご期待ください。 IoT Connect Gatewayにかける思い CI/CDの取り組みとサービスリリース ICGWの開発は、スピーディーに新機能を開発し、いち早くお客さまに提供するためにDevOpsチームとして開発、運用を行っています。 新機能開発・提供を実現するために以下のようなことをICGWのDevOpsチームでは取り組んでいます。このあたりの話もブログ投稿などでお話できればと思ってます。 1. Infrastructure as Code ICGWの環境構築作業は Terraform を利用し、コード管理で 開発環境、テスト環境、商用環境の構築を行っています。 これにより、新機能をリリースするために必要となる構成変更や拠点の追加をスピーディーに実現することが可能になりました。 2. Test as Code スピード感をもった開発も重要ですが、品質も重要ですので これまで通り品質を担保し、開発するための仕組みとして UnitTest, E2E Testなどの検証作業をGitHub Actionsで自動化することで従来の検証時間を削減しています。 また新機能追加でデグレが発生していないかをチェックし、品質を担保する仕組みを実現しています。 3. GitOps これまでの開発では、コード開発以外の作業や多大な時間が必要でした。 そこで、コンテナ化や Argo CD や Helm を利用することで、CI/CDを実現し開発者が開発に集中できる環境を実現し、商用環境に適応していくという仕組みを作りました。 また、Stg環境では、開発中の新機能を先行的にお客様やIoTデバイスベンダの方にトライアルして頂くなどの取り組みもすすめています。 個人的な思い このICGWは、私が小さなころから好きな 電子回路の世界 と大学院から夢中になった ネットワークやクラウドの世界 をつなぐサービスとして非常に思い入れがあるサービスです。 このサービス開発をはじめて、趣味でIoTデバイスをRaspberry PiやM5Stackなどを利用して色々と開発していますが、その根底には、 「つくるひと」 でありたいという思いがあると思っています。 以下の動画は2007年頃、とある番組の1000回放送記念CMとして１度だけ放送されたもので、リアルタイムに見て衝撃を受けたものです。 当時、分野をネットワークに変えて大学院進学するか悩んでおり、その後も、博士後期課程に進むか就職するかなど、いつも人生の大きな分岐点をこれまで支えてきてくれた大切な動画なので、紹介させてください。 この動画の中で、息子がただただ聞いてくる「なんでこの会社にしたの？」という無邪気な質問に対して、私達は自身の勤める社名に置き換えた時、「自分の子供が納得する答え」、「自分自身が納得できる答え」を出せるでしょうか？ 私の場合、「なんでNTT Com/NTTグループにしたの？」という質問に対して、父親の回答である「つくる人になりたかった」を 「つくる人であると共に、つなぐ人になりたかった」 と息子に自身をもって言えるよう、これからもサービス開発に取り組みたいとおもっています。 最後に IoTサービス関係者、クラウドサービス提供者などみなさんと共に、 私達の技術が誰かの何かの役に立ちたい 、またその先にいる 利用者の幸せに貢献できれば という思いをもって、これからもサービス開発を続けていきたいと思っています。 それがNTT Comが掲げる Re-connect X と自分は思っています。 この思いは、弊社のNTT Com Engineers' Blog投稿者の共通の思いであると思っています。そんな会社にしていきたいと思っていますので、これからも NTT Com ならびに NTT Com Engineers' Blog をよろしくお願い致します。 次回予告 今回は、ICGWのご紹介とICGWにかける思いの投稿になってしまいましたが、次回はICGWの使い方や、ICGWを使った電子工作やアプリの記事を投稿する予定です。 to be continued... ICGWに関するお問い合わせ先 トライアル、サービス導入に関するお問い合わせ 資料請求・お問い合わせフォーム 開発チームへのお問い合わせ メールを送る ※お手数ですが＠を半角文字に置き換えてください

こんにちは、デジタル改革推進部の河合と浅野です！ 私たちデジタル改革推進部では、普段から全社で使うためのデータ分析環境の開発・提供を行っています。 今回は社内でデータ分析コンペティションを開催したのでその内容を報告します。 社内データ分析コンペティションとは？ 社内にある様々なデータ活用課題をコンペティション形式に落とし込み、全社で知恵をしぼって解こうという試みです。 もともと、データサイエンスの界隈ではKaggleやatmaCupと呼ばれる分析力を競うコンペが行われており、課題や技術を集団で共有して解く文化があります。 今回はそれらを参考に、社内のデータを使ったコンペを 6/21~7/2 の２週間にかけて初開催しました。 開催にあたって期待したことは、以下の３つです。 様々な部署に散らばっているサービス特有のドメイン知識、データ、分析技術を一箇所に集める 優れたソリューションを集合知によって短期間で探し出す データ活用人材の育成や発掘 上記を満たすために、KaggleやatmaCupを参考にコンペのルールを工夫して作りました。 具体的には下記のような点です。 予測結果の設定 特定期間に過学習してしまうのを避けるため、予測範囲を2種類に分けて評価する。 一方は予測値を投稿すると即時計算されるpublic scoreに、もう一方は最終日まで結果がわからず順位決めに使われるprivate scoreとして評価する。 情報共有に対する評価 参加者は分析結果を適宜共有する（Discussion）ことができ、そこにいいねやコメントをつけることが可能。いいね数が上位の方も表彰対象とする チームでの参加も可能とする コンペのテーマと進め方 第一回のテーマとして、インターネットのトラフィック量(※通信量のこと)の将来予測を設定しました。 必要な分析技術の範囲としては、複数地域のトラフィックを予測する多変量の時系列予測となります。スコアとしては平均絶対パーセント誤差(MAPE)を使いました。 コンペティションは以下のようなスケジュールで実施しました。 6/21(月) 開会式:　テーマの説明 6/22(火) 初心者向け講座#1 データの読み込みからベースラインのsubmitまでのチュートリアル 6/24(木) 初心者向け講座#2 応用コンテンツの紹介。 EDA/validation評価について 6/28(月) もくもく会#1 6/29(火) もくもく会#2 7/2(金) ~17:30 コンペ終了 7/6(火) 結果発表・閉会式 7/14 成績上位者の発表. 分析内容の共有会 今回のイベントはフルリモートのオンライン開催でしたが、 コンペ初参加の方でもイベントに入りやすいように、初心者向け講座を複数回 また分析作業内容や疑問点を解消するためのもくもく会も複数回実施しました。 これらに参加すれば、誰でも共有されたサンプルコードを使って 予測結果を作って投稿できるような形にしています。 コンペ環境 デジタル改革推進部では、NTTcom内のデータ活用を推進するためDLXと呼ばれる全社員が使える分析基盤を開発しています。 今回はこの分析基盤にコンペ参加者に向けてJupyter labベースの環境を用意し、PythonやRを使って分析できるようにしました。 データセットはhadoop上に置き、trinoと呼ばれる分散SQLクエリエンジンを使って自由に参加者がSQLを叩いてアクセスできるようになっています。 また、某コンペサイトを参考に、社内コンペサイト「Saggle」を用意し、予測結果の投稿やコードの共有ができるようにしました。 分析Notebookの共有 リーダーボード 結果 ５０名を超えるエントリーをいただき、最終的なsubmit回数は800回を超えました。 参加者の予測誤差のスコア(public)の推移は以下のような感じでした。 コンペが進むにつれ全体のスコアが良くなっていく様子がみて取れます。 一方でprivate scoreの方も合わせて見てみると、分析コンペでありがちな過学習が発生していたのがわかります。 今回はsubmit回数の制限を行わなかったこともあり、public scoreを追い求めすぎてprivate scoreが下がり、最終順位が下がる(shake down)という悲しい思いをされた参加者が多かったと思います。 順位発表後には、スコア上位者の方に使った手法を解説していただきました。 参加者の声 開催後、参加者の方からアンケートを取ったところ 課題がやや難しかったという意見もありましたが、 「知識が無いなりにも操作ができる環境・サンプルコード準備を始め、基礎的な質問への応援サポートに感謝感謝でした」「初めてのコンペ参加でしたが、ディスカッションも盛り上がり、いろいろな気付きがあって大変楽しむことができました」 といった意見を多数いただくことができました。 このうち90%以上の方から、「次回開催があれば他の社員にも参加をお勧めしたい」と回答をいただき、社内でも非常にポジティブな意見をいただくことができました。 まとめ 今回は社内の実データを使った分析コンペの開催報告でした。 今回の分析コンペによって下記のような結果が得られました。 共通のデータを使って多様なスキルやバックグラウンドを持つ社員が議論しながら一つの分析課題に取り組むことができた 2週間という短い期間でデータの理解とより高精度な予測モデルを作成することができた 初めてコンペに参加した方/分析知識がなかった方を含め50名以上の方が、データ分析、予測までできるようになった 今後は、アイデアソンなどもう少し範囲を広げて分析コンペを定期開催できるよう目指していきたいと考えています。 これからもコムのデータ活用が盛んになり、業務やサービスをよりよくしていけるように取り組んでいきます！

職場体験型インターンシップ（エンジニアコース）募集中です！ (~2021/8/20) 本インターンシップは、実際に各分野でエンジニアとして働いているNTTコミュニケーションズの社員と一緒に働くことで、実際の開発現場を肌で感じて頂くことができるインターンシップです。 業務体験を通じて、NTTコミュニケーションズにおけるエンジニアの仕事が理解できるだけでなく、職場体験を通してみなさん自身が成長を実感できる内容になっています。 参加者からは「エンジニアの仕事が理解できた」「自分の活躍のイメージが湧いた」などの声も毎年多数頂いています。 また、参加いただいた学生の方から、次のようなアウトプットもいただいております。 NTTコミュニケーションズでインターンシップをしてきました!! NTTコミュニケーションズ インターンシップレポート 働くイメージを持ちたい方、自分のスキルや能力がどのように活かせるのかを知りたい方はぜひご応募ください！ 募集中のエンジニア種別は次のとおりです。 AIエンジニア ソフトウェアエンジニア ネットワークインフラエンジニア セキュリティエンジニア テレプレゼンスエンジニア その他詳細情報は、 募集ページ をご覧ください。みなさんのご応募をお待ちしております！ ※新型コロナウイルス感染状況により、開催の中止・開催内容の変更等の可能性があります。 ※夏インターンで実施するものは、エンジニアコースのみとなります。

こんにちは、イノベーションセンターの田良島です。普段はコンピュータビジョンの技術開発や検証に取り組んでいます。7月27日から30日にかけて、画像の認識と理解技術に関する国内会議の MIRU2021 が開催され、NTT Comからは計4名が参加し2件の発表をしました。 7/27(火)-7/30(金)にオンラインで開催される、画像の認識・理解シンポジウム( #MIRU2021 ) において、弊社イノベーションセンターから2件の研究成果を発表します！ 映像AI分野の研究者・エンジニア・学生が集う国内最大級の学会です。 学生は参加費無料✨ ぜひご参加ください▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月27日 画像の認識・理解シンポジウム( #MIRU2021 ) において、本日28日(水)のプログラムに、弊社の田良島が登場します！ ■15:00-15:30　口頭発表（ショート2） ■17:15-18:30　インタラクティブ1-2 「One Shot Deep Model for Multi-Actor Scene Understanding」 詳細はこちら▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月28日 画像の認識・理解シンポジウム( #MIRU2021 ) にて、弊社の丹野、市川、島田、木村、泉谷が研究成果を発表します！ ■7/29(木) 15:45-17:00 「プロセスデータおよび炉内映像Optical-Flowに基づくマルチモーダル深層学習によるごみ焼却プラントの蒸気量推定」 詳細はこちら▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月29日 ここでは、参加メンバーでMIRUの報告をしたいと思います。 ※なお私たちのチームでは、2021年8月4日現在エントリー受付中の 職場体験型インターンシップ に、 AI/MLシステムとの統合を志向した、メディアAI技術の研究開発 というポストを出しています。学生さんであればどなたでも応募可能です、ご興味あればぜひエントリーを検討ください！ MIRU2021 MIRUはコンピュータビジョンや画像映像認識を扱う国内最大級の学会です。個人的には、MIRUは SSII と並んで画像映像認識を対象とした国内学会の二大巨頭をなしている印象があります。MIRUの方がよりアカデミックな雰囲気 今年は過去最多の1,428名の参加があった とのことで、この技術分野の勢いをひしひしと感じます MIRUの発表区分(招待講演等を除く)には口頭発表(ロング、ショート)とインタラクティブ発表があり、前者は査読があります。今回NTT Comからは、口頭発表(ショート)1件とインタラクティブ発表1件を行いました。以下ではまず、口頭発表の機会をいただいた "One Shot Deep Model for Multi-Actor Scene Understanding" についてご紹介します。 NTT Comからの発表 この研究では、不特定多数の人物(アクター)が写る映像を入力としてそのシーンを認識する問題に取り組んでいます。より具体的には、アクターを検出・追跡することに加え、各個人がとる動作と、アクターが集団でとる行動とを認識するという問題です。集団の行動は、チームスポーツでのセットプレイをイメージしていただくと分かりやすいかもしれません。アクターはシーンの中でお互いに影響を及ぼし合うので、特に個人の動作や集団の行動の認識では、アクター間の相互作用を捉えることも重要になってきます。 アプローチとして、アクターの検出・追跡・個人動作認識・集団行動認識の各サブタスクにState-of-the-art(SOTA)の方法を適用するというものがまず思いつきます。ですがこのアプローチには、全体の処理が冗長でかつ時間がかかってしまう問題があります。どのサブタスクにも何かしらの深層学習モデルを用意することになり、かつそれらはしばしば同じバックボーンであったりするので、当然と言えば当然です。一方で各サブタスクについて考えてみると、例えば同一人物は前後のフレームで同じ動作を継続している可能性が高いなど、それらは少なからず関係し合っていることに気が付きます。サブタスクは関係し合っているのに各々は独立に解くというアプローチには、改善の余地がある気がしてきました。 このモチベーションのもと、本研究では上記の全サブタスクを解くための特徴をワンショットで出力可能なモデルを提案しています。モデルは、各フレームから検出、追跡、行動/動作認識のための特徴抽出を担う畳み込みニューラルネットワーク(CNN)、行動/動作特徴をその相互作用を考慮して変換するニューラルネットワーク(Relation Encoder)とから構成しています。Relation Encoderでは、Transformer 1 で採用されているMulti-Head Attentionを拡張し、アクターの見え方と位置どちらの情報もふまえた特徴変換を実現しているところがポイントです。 Volleyballデータセット 2 という代表的なベンチマークで評価したところ、各サブタスク毎にSOTAを適用するアプローチと同等の性能を、全体で約半分のモデルサイズおよび2倍の処理速度で実現できることが確認できました。 発表はZoomのウェビナーで実施し、およそ450名の方に聴講いただきました。またインタラクティブ発表はoViceで実施し、多くの方と直接ディスカッションさせていただきました。MIRU運営の皆様や聴講・質疑くださった皆様、まことにありがとうございました。この分野の競争は本当に激しいなと感じていますが、来年以降もぜひ私たちの取り組みを発表していけるよう頑張りたいです。 気になった発表 こんにちは、イノベーションセンターの鈴ヶ嶺です。普段は、クラウド・ハイブリッドクラウド・エッジデバイスを利用したAI/MLシステムに関する業務に従事しています。私からは3件気になった発表をご紹介します。 L1-2 動的光線空間のシングルショット撮影 概要 時間成分を含んだ動的な光線空間をシングルショット撮影から復元する手法を提案していました。光線空間とは様々な角度から撮影した画像を利用した多視点画像群で3次元ディスプレイなどに応用されます。従来的なカメラアレイでは装置の大規模化という課題、レンズアレイ型のplenoptic cameraでは一台のカメラで撮影できる代わりに視点ごとの空間解像度が低下するという課題があります。 例: 大規模なカメラアレイシステム 3 提案法では、1台のカメラの開口面と撮像面で得られる情報を適切に2次元上に符号化し、CNNで5次元の動的な光線空間を復元し高解像度、高フレームレートを実現していました。さらにハードウェアによる検証も実施しており、実応用上の有効性も示していました。 所感 1台のカメラにある開口面と撮像面の関係が光線空間を表現していることを利用し、それを2次元空間上に符号化し復元する発想が面白かったです。さらにハードウェアでも検証が成功しており、今後の応用が期待される研究でした。 L2-1 連動する骨格動作の表現に適した時空間特徴の学習による人物運動予測法 概要 人物骨格動作の予測モデルにおいて動作特徴を時間的・空間的に集約するアーキテクチャを提案していました。 人物運動予測モデルには、2つ課題があります。まず直前の動作が支配的なケースや、長期的な動作が支配的なケースなど参照すべき特徴が異なる時間的問題です。次に、局所的な動作のみを考慮すれば良いケースと大域的な動作を考慮しなければならないケースなど参照する特徴が異なる空間的問題です。提案法では、時間的問題に対してMultiscale Temporal Convolution 4 のそれぞれの中間層を用いて参照時間の異なる特徴を表現することで時間的に集約しています。空間的問題に対しては、Encoderでは位置ベースの空間に出力し、Decoderに角度ベースの空間を入力として利用していました。それぞれの空間は位置と回転ベクトルのヤコビ行列から2つの特徴量空間間のヤコビ行列を生成して写像されます。これらの手法から、高い性能を示す予測結果を提示していました。 所感 EncoderとDecoderで位置と角度という異なる特徴を用いることで空間的に頑健な予測モデルにしている点が面白かったです。実際のデモを見ても高い精度で予測されており、興味深い研究でした。 L5-3 An Improved Inter-intra Contrastive Framework for Self-supervised Video Representation Learning 概要 この発表では、動画に関する対照学習 5 の手法Inter-Intra Contrastive(IIC) 6 を改良したIICv2を提案していました。 IICの全体像 主にIICv2は3つの要素が拡張されています。1つ目がAnchorであるフレーム群からFrame repeating, Temporal shuffling, Clip rotationなど操作をして対照学習の負例を生成するintra-negative sampleです。2つ目は画像に対してのStrong data augmentations 7 です。3つ目はContrastive lossが適用される空間に表現をマッピングする小さなネットワークであるprojection head 8 です。実験結果として UCF101 9 , HMDB51 10 のデータセットにおいて最新のSOTAを上回る結果を示していました。 所感 動画に対する対照学習において、負例の生成方法や効果的なデータの水増し法などの様々な改良をしており勉強になりました。最終的な性能も現在のSOTAを上回っており、今後の参考にしたいと思いました。 こんにちは、イノベーションセンター新入社員の齋藤です。普段は、今回一緒に参加している鈴ヶ嶺と同じく、クラウド・ハイブリッドクラウド・エッジデバイスを利用したAI/MLシステムの研究開発をコンピュータビジョンを題材に取り組んでいます。私からも3件気になった発表をご紹介します。 L1-3 Can Vision Transformers Learn without Natural Images? arXiv:2103.13023 概要 Vision Transformer(ViT) 11 の性能は、学習に用いるデータセットサイズに強く影響を受けることが知られていますが、大規模なデータセットを用意するにはコストや倫理の問題が生じます。この研究では、数式から画像とラベルを自動生成する FractalDB 12 を用いてViTの事前学習を行うと、自然画像とその正解ラベルを用いて学習した場合とほぼ同精度が得られる、つまり自然画像を用いることなくViTの事前学習は可能だという驚くべき結果が示されています。 評価 ・FractalDBで事前学習したViTとImageNet-1k 13 ,Places-365 14 などを事前学習させたViTを比較した実験 ・FDSL(FractalDB-10k)とSSL(Jigsaw 15 , Rotation 16 , MoCov2 17 , SimCLRv2 18 )の比較実験を行っています。 Computer Vision and Pattern Recognition (CVPR). (2009) 248–255 DeiTsで事前学習済みのFractalDB-1k/10kがImageNet-100/Places-30のモデルを上回り、ImageNet-1k/Places-365を上回ることはできませんでした。ですが、ImageNet-1kと肉薄した性能を持っていることが実験から分かりました。 FractalDB-10KはSimCLRv2よりも若干精度を上回った結果を出しました。また、C10、VOC12、P30においては精度を上回った結果を出しています。 所感 今後、研究が発展することにより様々なタスクへの応用可能性が高いため、楽しみな研究の1つになりました。ソースコードもオープンソースで公開されているので、手元で試してみたいとも思います。 L2-4 Lightning-fast Virtual Try-on without Paired Data and Direct Supervision 概要 この研究では、弱教師あり学習を用いて、仮想試着を提案しています。仮想試着とは、Sourceの画像に対して、Targetの服に着せ替える技術のことで、応用先として、アパレルのECショップなどがあります。従来手法の、アノテーションコスト、メモリの消費量、テスト速度の問題を解決するものとして、本発表の手法 (LiVIRT) を提案しています。エンジンの中身としては、3つのネットワークを用いています。その中で無駄を取り払うなどの工夫によるネットワークの高速化を行っています。 評価 データにペアデータがある場合の実験では、教師あり学習の手法(CP-VTON 19 , SieveNet 20 )とLiVIRTの比較を行い、教師あり学習とほぼ同じ精度で仮想試着ができています。 ペアデータが存在する場合の実験においても、精度が良いことが実験で示されています。 所感 私が試したことのある仮想試着は、実際に着ている感があまりありませんでした。仮想試着の技術はECサイトのUX向上に大きく影響すると思うので、興味深く発表を聞かせていただきました。 L5-1 複屈折反射特性の計測に基づく材質識別 概要 材質識別は、資源の開発やリサイクル、自動運転など様々なシーンで求められる技術です。この研究では、複屈折反射特性から抽出された特徴量をU-net 21 に入力してクラス分類を行っています。 評価 79種類の材質を、金属・木材・布・樹脂・石材に材質クラスの識別を行っています。U-netと比較する手法としては、k近傍法を用いています。結果として、5種類の材質クラスの識別平均正解率は、U-netで0.90、k近傍法で0.87となり、U-netを用いた方が正解率が高いことが確認できました。 所感 複屈折反射特性から特徴量を求めている点が面白いと感じました。モデルのバックボーンを変えた場合の精度変化も気になるところです。 最後に MIRU2021の模様をご紹介しました。NTT Comでは、今回ご紹介した学会での発表調査はもちろんのこと、画像や映像、更には音声言語も含めた様々なメディアAI技術の研究開発に今後も積極的に取り組んでいきます。また一緒に技術開発を進めてくれる仲間も絶賛募集中です。 アカデミックな研究に注力したくさん論文を書きたい 最新の技術をいちはやく取り入れ実用化に結び付けたい AIアルゴリズムに加え、AI/MLシステム全体の最適な設計を模索したい という方々に活躍していただけるフィールドが弊社には多くあり、いくつか新卒採用のポジションを用意する予定です。エントリーの受付開始は2022年1月以降となる予定ですが、よろしければぜひ新卒採用ページをウォッチしていただけると嬉しいです さらに冒頭でも述べた通り、2021年8月4日現在、NTT Comでは 夏の職場体験型インターンシップ のエントリーを受付中です。私達のチームからも、AIエンジニアカテゴリに AI/MLシステムとの統合を志向した、メディアAI技術の研究開発 というポストを出しています。インターンを通じて、会社やチームの雰囲気、そして私たちの取り組みを知っていただく機会にできればと考えています。皆様のご応募、心からお待ちしています！ Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., … & Polosukhin, I. (2017). Attention is all you need. In Advances in neural information processing systems (pp. 5998-6008). arXiv:1706.03762 ↩ Ibrahim, M.S., Muralidharan, S., Deng, Z., Vahdat, A., & Mori, G. (2016). A Hierarchical Deep Temporal Model for Group Activity Recognition. 2016 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 1971-1980. ↩ 裸眼立体ライブ映像システムを支えるカメラアレイの開発 https://news.mynavi.jp/photo/article/20080625-cameraarray/images/004l.jpg ↩ Lea, C., Flynn, M. D., Vidal, R., Reiter, A., & Hager, G. D. (2017). Temporal convolutional networks for action segmentation and detection. In proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 156-165). arXiv:1611.05267 ↩ Khosla, P., Teterwak, P., Wang, C., Sarna, A., Tian, Y., Isola, P., … & Krishnan, D. (2020). Supervised contrastive learning. arXiv preprint arXiv:2004.11362. arXiv:2004.11362 ↩ Tao, Li, Xueting Wang, and Toshihiko Yamasaki. “Self-supervised video representation learning using inter-intra contrastive framework.” Proceedings of the 28th ACM International Conference on Multimedia. 2020. arXiv:2008.02531 ↩ Grill, J.-B., Strub, F., Altche, F., Tallec, C., Richemond, P. H., ´Buchatskaya, E., Doersch, C., Pires, B. A., Guo, Z. D., Azar, M. G. et al.: Bootstrap your own latent: A new approach to self-supervised learning, Advances in Neural Information Processing Systems (2020) ↩ Chen, T., Kornblith, S., Norouzi, M., & Hinton, G. (2020, November). A simple framework for contrastive learning of visual representations. In International conference on machine learning (pp. 1597-1607). PMLR. ↩ Soomro, K., Zamir, A. R. and Shah, M.: UCF101: A dataset of 101 human actions classes from videos in the wild, arXiv preprint arXiv:1212.0402 (2012). ↩ Kuehne, H., Jhuang, H., Garrote, E., Poggio, T. and Serre, T.: HMDB: A large video database for human motion recognition, IEEE International Conference on Computer Vision, pp. 2556–2563 (2011). ↩ Dosovitskiy, A., Beyer, L., Kolesnikov, A., Weissenborn, D., Zhai, X., Unterthiner, T., … & Houlsby, N. (2020). An image is worth 16x16 words: Transformers for image recognition at scale. arXiv preprint arXiv:2010.11929. arXiv:2010.11929 ↩ H. Kataoka, K. Okayasu, A. Matsumoto, E. Yamagata, R.Yamada, N.Inoue, A. Nakamura, and Y. Satoh. Pre-training without Natural Images. In Asian Conference on Computer Vision (ACCV), 2020. arXiv:2006.10029 ↩ Deng, J., Dong, W., Socher, R., Li, L.J., Li, K., Fei-Fei, L.: ImageNet: A LargeScale Hierarchical Image Database. In: The IEEE International Conference on ↩ Zhou, B., Lapedriza, A., Khosla, A., Oliva, A., Torralba, A.: Places: A 10 million Image Database for Scene Recognition. IEEE Transactions on Pattern Analysis and Machine Intelligence (TPAMI) 40 (2017) 1452–1464 ↩ Noroozi, M., & Favaro, P. (2016, October). Unsupervised learning of visual representations by solving jigsaw puzzles. In European conference on computer vision (pp. 69-84). Springer, Cham. ↩ Gidaris, S., Singh, P., Komodakis, N.: Unsupervised Representation Learning by Predicting Image Rotations. In: International Conference on Learning Representation(ICLR) (2018) arXiv:1803.07728 ↩ Chen, X., Fan, H., Girshick, R., & He, K. (2020). Improved baselines with momentum contrastive learning. arXiv preprint arXiv:2003.04297. arXiv:2003.04297 ↩ Chen, T., Kornblith, S., Swersky, K., Norouzi, M., & Hinton, G. (2020). Big self-supervised models are strong semi-supervised learners. arXiv preprint arXiv:2006.10029. arXiv:2006.10029 ↩ Bochao Wang, Huabin Zheng, Xiaodan Liang, Yimin Chen, Liang Lin, Meng Yang.“Toward Characteristic-Preserving Image-based Virtual Try-On Network”.arXiv preprint arXiv:1807.07688. arXiv:1807.07688 ↩ Surgan Jandial, Ayush Chopra, Kumar Ayush, Mayur Hemani, Abhijeet Kumar, Balaji Krishnamurthy.“SieveNet: A Unified Framework for Robust Image-Based Virtual Try-On”.arXiv preprint arXiv:2001.06265. arXiv:2001.06265 ↩ O. Ronneberger, P. Fischer, T. Brox, ”U-net: Convolutional networks for biomedical image segmentation”, MICCAI, 2015 ↩

こんにちは、イノベーションセンターの前田です。今回は、前回に引き続き、私のチームで開発中の制御（OT）システム向けセキュリティ対策技術OsecT（オーセクト）についてご紹介します。 前回の記事（前編）では、以下の内容をご紹介しました。 OTネットワークの概要 OTネットワークのセキュリティ対策と課題 OsecTの概要 OsecTのネットワーク可視化機能の詳細 本記事では、 OsecTの脅威検知機能の詳細 について、ご紹介します。 前編のおさらい 工場・ビル等のスマート化に伴い、OTネットワークのセキュリティリスクも高まっています。しかし、OTのネットワークは閉域ネットワークとして構築されてきたことや独自OS・プロトコルが多数利用されてきたことから、セキュリティ対策が進んでいない現状があります。こうした状況を受けて、NTT Comでは、OTのセキュリティ対策技術OsecT（オーセクト）を開発しています。 OsecTには、 守るべき資産や通信の可視化を行うネットワーク可視化機能 と、 不正に接続された端末やサポート切れのOSを利用する端末等を検出した際のアラート機能（脅威検知機能） の2つの機能があります。 以降では、OsecTの脅威検知機能の詳細について、開発の工夫点などを交えながらご紹介します。 ※OsecTは現在開発中の技術であり、正式リリース時には仕様・画面イメージが変わる可能性が大いにあります。 脅威検知機能 OTの守るべき資産・ネットワークを可視化し、資産台帳の最新化や監視ポイントの明確化等が行えたら、次のステップとして有用なのが脅威検知機能になります。 こちらの機能もネットワーク可視化機能と同様に、オフラインのトラヒックデータを元に定期アセスメント等で利用する使い方もできますが、リアルタイムのトラヒックデータをミラーリングで取り込んで脅威検知機能で処理し、発出されるアラートを監視する使い方が有効です。 OsecTでは、以下の7つの脅威検知機能を開発中です。機能毎にコンテナを分けることで、必要なものだけを選択して導入できる作りにしています。 また、各脅威検知機能は、次のいずれかに属しています。 学習期間を定めてその期間を正常状態として学習し、検知期間において、学習モデルと異なる振る舞いが観測された場合にアラートを発出する「アノマリ検知」 セキュリティの脅威につながる通信パターンやサポート切れのOS情報などを事前定義したルールに基づき検知期間の通信をチェックし、ルールにマッチした場合にアラートを発出する「ルールベース検知」 新規端末検知 こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{IPアドレス, MACアドレス}の組み合わせを学習して、学習モデルに登場しない{IPアドレス, MACアドレス}の組み合わせの通信が観測された場合にアラートを発出しています。 アラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{IPアドレス, MACアドレス}の組み合わせに加えて、当該端末を特定しやすいように、MAC Vendorの情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、計画されていない端末がネットワークに接続された際などに早期発見することができます。 ネットワークホワイトリスト こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。 OTの独自サービスのプロトコルの中には、一般的な通信サービスの振る舞いとは異なり、送信元ポート番号が固定値で、宛先ポート番号がランダム or 範囲の値を取るものがあります。こちらの特徴を考慮せずにネットワークホワイトリストの学習モデルを作成すると、学習モデルの行数（テーブル数）が膨大になる問題があります。OsecTでは、こうしたサービスの通信を自動判別・集約して効率的に学習しています。 学習モデルは、例えば、以下のようなものが作成され、4行目や7行目が前述の仕組みで集約された箇所になります。 また、ネットワークホワイトリストのアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示するようにしています。こちらのアラートを見ることで、平常時とは異なる宛先への通信や平常時に利用していない不審なサービスの通信などを早期発見できます。 OTコマンドホワイトリスト こちらは、アノマリ検知に属し、OTプロトコルのL7情報を用いた脅威検知機能になっています。 現在は、ビルのオートメーション・制御に利用されるBACnet/IPに対応しており、学習期間のトラヒックデータに登場する、{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。 OTコマンドホワイトリスト（BACnet/IP）のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示しています。こちらのアラートを見ることで、平常時とは異なるBACnetサービス（コマンド）通信の発生を早期発見でき、例えばビルシステムの保守作業スケジュール等と突合して適切な通信かを確認することで、異常を特定できます。 流量ベースライン検知 こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス}のペア毎に、各時間帯のトラヒック量（パケット数、バイト数）をベースに、各時間帯で取り得るトラヒック量の範囲（上限値と下限値）を推定して、その値を学習モデルとして保存します。検知期間では、学習されたトラヒック量の上限値を上回る/または下限値を下回る通信が観測された場合にアラートを発出します。また、OTでは決められた時間に機械的に通信する端末が多く存在するため、{src_ip, dst_ip}のペア毎に、各時間帯での通信の有無を学習して、平常時は通信が発生する時間帯にもかかわらず、通信が発生しなくなった場合にもアラートを発出しています。 OTでは、工場等が稼働している日なのか、非稼働の日なのかによって、通信量や頻度の傾向が大きく異なる場合があるため、こちらの機能では、非稼働日や非稼働の時間帯を設定できるようにしています。非稼働日・時間帯の場合は、稼働日とは別のベースライン（上限値と下限値）を作成して検知に利用します。 流量ベースライン検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、送信元IPアドレス、宛先IPアドレス、アラート種別（上限値を上回った/下限値を下回った/通信が停止した）、データ種別（パケット数/バイト数）、観測した通信量、学習された通信量の上限値、学習された通信量の下限値、通信断の判定に利用されるカウンタの値などを表示しています。また、他の脅威検知と同様に、IPアドレスにマウスカーソルを合わせた際の端末情報の吹き出し表示もあります。 例えば、画像の2行目では、2019/08/20 6:30において、10.1.0.232から10.1.0.55へのパケット数が学習された上限値の483個に対して、10052個観測されており、上限値を超えたことでアラートが発出されています。 流量ベースライン検知ではさらに、通信量の変化や異常性を分かりやすくするために、次のような時系列グラフで、観測された通信の詳細を確認できるようにしています。 こちらのグラフでは、赤線が学習された上限値、青線が学習された下限値、黒線が観測値を表しています。また、グラフ上の点にマウスカーソルを合わせることで、観測された値や通信に含まれるサービスの内訳を吹き出しで表示しています。さらに、こちらの画面で分析に必要な情報が極力完結するように、画面右には、送信元IPアドレスと宛先IPアドレスに紐づく端末の詳細情報を表示しています。こちらのアラートや通信の詳細ページを見ることで、平常時からの急激な通信量の増加や攻撃等でのシステム停止による通信断などを早期発見できます。 周期異常検知 こちらは、アノマリ検知に属し、BACnet/IPに特化した脅威検知機能となっています。学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、信号処理技術を用いて、通信周期（60秒に1回、通信発生など）を抽出して学習します。検知期間では、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}毎に、通信周期を抽出し、学習された周期と比較して、周期外の通信が発生した場合、または周期的な通信が消失した場合にアラートを発出します。 こちらは、NTTの社会情報研究所で考案された 技術 がベースとなっており、複数のビルの通信データを分析して得られたノウハウに基づき、アルゴリズムの構築、特徴量・各種パラメータの設定を行っています。 周期異常検知の学習モデルは、次のようになっています。 こちらでは、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、学習された通信周期(PRI)、学習時に非周期として判定された通信数(non_periodic)、最終判定されたモデル(period=通信に周期性あり、non=通信に周期性なし、period_and_non=通信に周期性ありとなしが混在)などを表示しています。学習された通信周期(PRI)の項目は、(時間間隔, 通信回数)で表記されるようになっており、例えば、(62, 3)は、62秒毎に3回ずつの通信が発生することを意味しています。また、周期性なしの場合は(-1, 1)が表示されます。なお、1行目の[(62, 3), (-1,1)]は、通信を分解した際に、周期性のある通信と非周期の通信が混在していることを意味しています。 また、周期異常検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、アラートの内容(Non Periodic communication=周期外通信の発生、Lost Communication=周期通信の消失)、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ、ホバーで端末の詳細情報を表示しています。こちらのアラートを見ることで、BACnet/IPにおける不正なコマンドの挿入や通信断を早期発見できます。 サポート切れOS端末検知 こちらは、ルールベース検知に属します。サポート切れOSの一覧表を事前ルールとして保持しており、検知期間のトラヒックデータの中に登場する{IPアドレス, MACアドレス}の組み合わせ毎にOSを推定し、サポート切れOSの一覧表の内容とマッチする場合にアラートを発出しています。 前編でご紹介したネットワーク可視化機能でも、OS推定情報を表示していますが、あちらは主に定期アセスメント等で利用することを想定しているため、様々なメトリックを利用して、少しでも古いOSの疑いがあれば表示するようにしているのに対して、脅威検知機能は主にリアルタイムにアラートを監視する使い方を想定しているため、運用者の負担を軽減する（誤検知を減らす）ように、確実性が高く、改ざんが困難なメトリックのみを利用してOS情報を推定しています。 サポート切れOS端末検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、{IPアドレス, MACアドレス}の組み合わせ、OS情報に加えて、当該端末を特定しやすいように、MAC Vendorとホスト名の情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、サポート切れのOSを利用する端末がネットワークに接続された際に早期発見できます。 シグネチャ検知 こちらは、ルールベース検知に属します。セキュリティの脅威につながる通信パターンの情報（シグネチャ）を事前ルールとして保持しており、シグネチャの内容に合致する通信が観測された場合に、アラートを発出しています。 こちらの機能では、オープンソースのIT向けIDS(Intrusion Detection System)である「 Suricata 」と、Proofpoint社が配布している ルールファイル （シグネチャ）を利用しています。 ルールファイルには、セキュリティの脅威につながる通信パターンを表すルールが複数記載されていますが、一例を挙げると、次のようなものがあります。 alert http $HOME_NET any -> any any (msg:"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"; flow:established,to_server; content:"Authorization|3a 20|Basic"; nocase; http_header; content:!"YW5vbnltb3VzOg=="; within:32; http_header; content:!"Proxy-Authorization|3a 20|Basic"; nocase; http_header; threshold: type both, count 1, seconds 300, track by_src; reference:url,doc.emergingthreats.net/bin/view/Main/2006380; classtype:policy-violation; sid:2006380; rev:13; metadata:created_at 2010_07_30, updated_at 2020_08_28;) Suricataのルールのフォーマットは、以下のようになっています。 action: シグネチャにマッチした際のアクション（例では、alert） header: ルールを適用するプロトコル、IPアドレス、ポート番号、通信の向き（例では、http $HOME_NET any -> any any） rule options: オプション（例では、(msg: から 28;) までの括弧で囲まれた部分） 上記の例は、http通信かつ監視対象のネットワークから任意のポート、宛先への通信を検査し、rule optionsで指定された条件を満たした場合に、"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"(ベーシック認証でHTTPパスワードが暗号化されていないことを検出したという意味)のアラートを発出するルールになっています。 rule optionsには、細かなマッチ条件などを;で区切って複数指定可能で、例えば、 flow:established,to_server; content:"Authorization|3a 20|Basic"; の部分は、フローが確立していてclient→server方向であること、ペイロードに"Authorization: Basic"が含まれること、を表しています。 正確なルールの読み方は、 公式ドキュメント をご参照ください。 OsecTでは、Suricataの出力結果を、次のようなアラート画面として表示しています。 こちらでは、当該通信が発生した時刻、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号、プロトコル、マッチしたルールの内容とカテゴリ、Severity（1: high, 2: medium, 3: low）を表示しています。また、他の脅威検知機能と同様に、極力こちらの画面だけで必要な情報を確認できるように、ホスト情報をホバー表示しています。 こちらのアラートを見ることで、脆弱性を含む古いJavaの利用や平文でのパスワードのやり取りなど、セキュリティの脅威につながる通信の発生を早期発見できます。 アラート統合画面 OsecTでは、ここまでにご紹介した7つの脅威検知機能のアラートをまとめて確認できる画面も作成しています。 こちらは、日常的にアラートを監視する際にメインで利用する画面をイメージして作成しています。送信元IPアドレスや宛先IPアドレスなどの条件を設定して、アラートをフィルタリングできるため、特定のIPアドレスに着目して、複数の脅威検知のアラートの有無を横断的に確認したい場合などにも利用できます。 最後に 今回は、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの脅威検知機能についてご紹介しました。工場等のスマート化を推進していく上では、これまであまり検討が進められていなかった、OTのセキュリティ対策を考えることが非常に重要になってきます。本記事の内容が、ご検討のお役に立ちましたら幸いです。また、本記事の感想やフィードバックもお待ちしております。 ※2021年6月現在、OsecTの実証実験のトライアル利用者様を募集しております。無償でご利用頂けますので、国内に制御システムをお持ちの製造業・インフラ事業者の方で実際にお試ししたいという方がいらっしゃいましたら、是非 こちら からご応募頂けますと幸いです。

イノベーションセンターの小林です。普段は、ある日は部内情シス、ある日は情報セキュリティオペレーションをやっています。以前の開発者ブログに寄稿したこともあり、今回の開発者ブログリニューアルにもかかわりました。 今回のリニューアルにあたっては、各記事に対する社内レビューと記事公開のプロセスを「いい感じ」にしたいよねとの声があり、現時点ではそれなりに満足いくものを作れました。その中身を少しご紹介します。 レビュー 以前の開発者ブログの頃から、寄稿された記事は有志によるレビューを通してから公開するようにしていました。主に見ていたのは文法的な間違いがないか、NTT Comの統一表現を使っているか、明らかな事実誤認や錯誤がないか、といったポイントです。このレビューの仕組み自体は、リニューアルにかかわった面々とのディスカッションを踏まえて、今回のリニューアル後も引き続き行うことにしました。 かつてのレビューは、Google DocsやWordなどで寄稿者がまとめた原稿に、レビュワーがコメントをつけて寄稿者に戻し、寄稿者が内容を修正した後ブログプラットフォームへ投稿する流れになっていました。このプロセス自体は一応動くには動くものの、開発者ブログの中身としてはあまり「いい感じ」の状態ではないね、との話はずいぶん前からありました。 どうしたか 今回のリニューアルに際し、次のような仕組みを作りました（説明のため一部割愛しているところがあります）。 簡単な流れはこうです。 寄稿者にはMarkdown形式で原稿を書いてもらい、画像（あれば）とともにGitHubにコミットします。そのコミットをpull requestにしてもらいます（図中の1）。 レビュワーは従来通り内容をチェックし、問題なければマージします（図中の2）。 マージをきっかけにGitHub Actionsによるデリバリプロセスがスタートし、原稿と画像を読み込んでブログプラットフォームのAPI経由で記事を送信、最終的に公開される仕組みです（図中の3と4）。 図中では表現していませんが、1でpull requestをオープンした時点でもGitHub Actionsが起動し、Linterによる文法・表現のチェックを行うようにもしました。記事が長いと見落としがちな表記揺れにも気づきやすくなります。 得られたこと GitHubのpull request機能に備わっているコメント機能（ソースコードの行を指定してコメントがつけられる）を使えるようになったこと、また変更前後の差分をすぐ引き出せるようになったことが大きいです。Google Docsでも任意の箇所にコメントをつけたり、修正を提案する機能もありますが、解決済みとしたコメントや修正を受け入れた箇所を後から探すことには困難が伴います。 また、ブログプラットフォーム本体の、投稿権限を持つユーザーをいたずらに増やさなくて済む点も挙げられます。投稿したい人はGitHubへのアクセスさえあればよく、プラットフォーム側のユーザー管理にかかる手間が削減できます。寄稿者にしてみても、エンジニアにとっては使い慣れた道具であるGitHubでライティングができることは、新たな学習コストをかける手間が省けます。 今後 GitHubとGitHub Actionsを中心としたエコシステムでは、まだいろいろできることがありそうです。 画像の適切なリサイズ、記事サムネイルの生成など画像に関する処理 表現チェックの自動化（textlintを使うなど） 社内Slackに新着投稿の通知を出して、コミュニティを盛り上げる……などなど 寄稿者、レビュワーほか開発者ブログにかかわる人にとって「いい感じ」のプラットフォームにしていければいいなとも思います。 もちろん読者の皆様にもメリットがある話だと思っています。「簡単に書ける」ことがNTT Com内に知れ渡れば、きっと隠れた寄稿者がどんどん出てきて、皆様にもどんどん新しい記事をお届けできる、はず。 今後の開発者ブログのコンテンツにもご期待ください！

こんにちは、イノベーションセンターの前田です。今回は、私のチームで取り組んでいる、制御（Operational Technology: OT）システムネットワークのセキュリティとその対策技術についてご紹介します。 本記事は前編と後編の2部構成となっており、 前編では、OTネットワークの概要やOTのセキュリティ対策・課題等の背景情報と、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの概要とネットワーク可視化機能 後編では、OsecTの脅威検知機能 について、それぞれご紹介します。 OTネットワークとは OTネットワーク（ICS: Industrial Control System ネットワークのように呼ばれることもあります）とは、ビル、工場、プラントなどの制御システムの管理・制御に利用されるネットワークです。 制御システムでは、従来、独自のOS・通信プロトコルが利用され、オフィス等の他のITネットワークから分離された閉域ネットワークとして構築されていたこともあり、セキュリティを意識した設計になっていませんでした。しかし、近年では、汎用OSへの対応、通信プロトコルの標準化やIP化が進められていることや、生産性・利便性の向上のためのスマート化に伴い、外部ネットワーク（オフィスITネットワーク・クラウド等）への接続が進められていることで、セキュリティリスクにさらされる危険性も増加してきています。 OTネットワークのセキュリティ対策と課題 OTネットワークとITネットワークでは、以下の図のように、セキュリティ対策の考え方に違いがあります。 ITのセキュリティではデータの機密性が重視されますが、OTのセキュリティではシステム停止時の事業や社会への影響が大きいため、機密性よりも可用性が重視されます。また、OTのシステムはライフサイクルが長く、サポート切れのOSを利用しているケースも多くありますが、基本的なセキュリティ対策である、OSの最新化やセキュリティパッチの適用などは、可用性を損なう危険性があるため、一般的には実施が困難です。 さらに、上の図の理想の絵のように、OT関連のセキュリティガイドラインでは、ITやOTなどのネットワークを機能階層毎に分離（セグメンテーション）してその境界を保護することが求められていますが、現実の絵のように、OTとITのネットワーク領域が混在していたり、セキュリティの監視ポイントが曖昧なまま運用されていたり、そもそもOTの資産を十分に把握できていなかったりするケースも多くあります。OTとITでは管理組織が異なり、セキュリティに対する意識も異なるため、ITの考え方で、OT側のセキュリティ対策を進めるのは容易ではありません。 （蛇足になりますが、OTのネットワークは、ITにあまり詳しくない方が設計されている場合もあり、過去の分析では、RFC1918で規定されたIPv4のプライベートアドレス帯(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)以外のアドレスをプライベートアドレスとして利用しているケースに遭遇したこともあります） OTセキュリティ対策技術 OsecT OTのセキュリティ脅威の高まりを受けて、NTT Comでは、OTのセキュリティ対策のための技術であるOsecT（オーセクト）を開発しています。 OsecTには、 守るべき資産や通信の可視化を行うネットワーク可視化機能 と、 不正に接続された端末やサポート切れのOSを利用する端末等を検出した際のアラート機能（脅威検知機能） の2つの機能があります。 また、既存の制御システムの可用性に影響を与えないように、次のような作りにしています。 NIDS(Network Intrusion Detection System)型で、エンドポイントへの対策ツールの導入が不要 既存スイッチ等でのパケットのミラーリング、または既存のpcapファイルを読み込ませることでネットワーク可視化と脅威検知を実施 ミラーリングも困難な場合は、ブロードキャスト通信のみで、限定的なネットワーク可視化・脅威検知を実施 パッシブな解析のみを実施（ネットワークに検査のための通信を流さない） OsecTは、リアルタイムのトラヒックデータを元にセキュリティアラートを監視する使い方とオフラインのトラヒックデータを元に定期アセスメント等で利用する使い方の両方に対応しています。 以降では、OsecTのネットワーク可視化機能の詳細について、開発の工夫点などを交えながらご紹介します。（なお、脅威検知機能は、後編の記事でご紹介します） ※OsecTは現在開発中の技術であり、正式リリース時には仕様・画面イメージが変わる可能性が大いにあります。 ネットワーク可視化機能 OTでは、守るべき資産や流れている通信を十分に把握できていないことが多々あり、このような場合に有用なのがネットワーク可視化機能になります。 資産台帳の自動生成 パケットから取得した情報を元に、こちらのような端末一覧を作成できます。 こちらは、IPv4/v6アドレス、MACアドレス、MAC Vendor、Service(プロトコルとポート番号)、Host Name、OS、通信が最初に観測された時刻、通信が最後に観測された時刻などの情報で構成されています。守るべき資産の把握や資産台帳の最新化に役立つ他、台帳に記載のない不審な端末やサポート切れOSを利用している疑いのある端末、ごく短期間のみ通信が観測された端末などの洗い出しにも利用できます。 OTの資産の可視化が可能ないくつかの製品では、MACアドレスとHost Nameを元に、資産の一覧を生成していますが、組み込み系機器では、Host Nameにデフォルトで機種情報などが格納されていることが多く、資産を正確に一覧化できなくなるため、OsecTでは、MACアドレス情報をメインで利用して資産の一覧を作成しています。また、こちらで可視化している情報の内、特に、OS情報では、 p0f といった既存のフィンガープリンティング技術を利用しつつ、複数のメトリックによる推定技術を適切に組み合わせることで、OS推定精度を向上させています。 IPアドレス情報の表示機能 こちらでは、IPアドレスの一覧情報や特定のIPアドレスの通信先一覧等を表示できます。 マトリックス表示機能 MAC Vendor、OS、端末の役割（client / server / 両方の性質を持つもの）を色分けして、縦16x横16のマトリックス形式（/24セグメント単位）で表⽰することで、多数の端末から構成されるOTネットワークを俯瞰的に見ることができます。 こちらは、MAC Vendor情報に基づくマトリックスになります。画面右側にMAC Vendor情報と色の対応を表示しています。また、マトリックスの特定の数字にカーソルを合わせることで、対応するMAC Vendor情報がホバーとしても表示されます。 こちらは、OS情報に基づくマトリックスになります。画面構成等はMAC Vendorと同様です。 こちらは、端末の役割に基づくマトリックスになります。画面構成等はMAC Vendorと同様です。 マトリックス表示機能によって、例えば、サポート切れのOSが多いネットワークセグメント等を視認しやすくなるため、対策・監視などを導入する箇所の検討に利用できます。また、ネットワークセグメント毎のIPアドレスの割り当てルールを視認しやすくなるため、想定しないIPアドレスを使っている疑わしい端末の発見にも利用できます。 ネットワークマップの作成 OsecTでは、資産（端末）の可視化だけでなく、端末間でやり取りされる通信も可視化できます。 こちらの機能では、注目すべきネットワーク構造や端末を抽出しやすくするための工夫として、次のようなことを行っています。 直接通信するIPアドレス同士を近くに配置し、直接通信していないIPアドレスを遠くに配置 各IPの役割（client、server、両方の性質を持つもの）を推定し、役割別に異なる色で表示 通信が集中しているIPアドレスを大きく表示 これにより、通信特性が似ているグループやグループ間の通信などが分かりやすくなり、各種ガイドラインで求められている、適切なネットワークセグメンテーションの検討やアクセス制御の検討に繋げることができます。また、管理者の方が想定していない端末間で通信が発生していないかを確認することで、グループ間を橋渡しするような攻撃経路の発見や、不正な通信を行う端末の発見などにも利用できます。 重要度/特異度の高い端末の可視化機能 ネットワークの中で重要な/特異性のある端末を可視化することで、多数の端末が存在するOTネットワークにおいて、優先的に対処すべき端末を抽出できます。 こちらでは、次数中心性(通信先の数が多いほど大きい値になる指標)と媒介中心性（通信を仲介している数が多いほど大きい値になる指標）の2つの軸に基づき、前述のマップを数学的なグラフとして解析することで、定量的に重要な端末や構造を理解できるようにしています。 次数中心性と媒介中心性が大きい端末ほど、ネットワークの中心に位置し、重要度の高い端末になります。OsecTでは、原点からの距離（distance）として定量化しています。 また、通常では、次数中心性と媒介中心性は比例することが多いですが、どちらか一方のみが大きい場合は、ネットワークの中で特徴的な役割を担っている可能性があるため、こちらも優先的に確認すべき端末になります。OsecTでは、次数中心性と媒介中心性のどちらかが大きい度合いを特異度（Specificity）という指標で定量化しています。 ランキング表示 MAC Vendor、ホスト毎のトラヒック量、サービス毎のトラヒック量などをランキング表示できます。こちらは、ネットワークの特徴や全体傾向を把握するのに役立ちます。 こちらは、MAC Vendor情報のランキングになります。全体傾向の把握のほか、利用していないベンダの端末が存在しないかの確認にも利用できます。 こちらは、通信量が多い端末のランキングになります。 こちらは、通信相手の数が多い端末のランキングになります。 こちらは、通信量が多い通信サービスのランキングになります。第2位のBACnetは、ビルのオートメーション・制御に利用されるOTプロトコルです。また、OTの独自サービスのプロトコルの中には、一般的な通信サービスの振る舞いとは異なり、送信元ポート番号が固定値で、宛先ポート番号がランダム or 範囲の値を取るものがあります。OsecTには、こうしたサービスを自動判別する仕組みがあり、第3位の(15100/udp/srcport_aggregated) は、送信元ポート番号が15100/udpであり、宛先ポート番号が発散しているサービスであることを意味しています。 こちらは、利用しているホスト数の多い通信サービスのランキングになります。 通信量の時系列表示 通信量(bps/pps)を時系列で表示できます。 こちらの機能を利用することで、通信量の傾向を把握したり、通常の通信量から逸脱する異常な通信量の増加などを発見できます。画像の例では、8/20頃に急激な通信の増加が発生していることが確認できます。 差分分析表示 任意の2つの期間を指定して、資産情報の変化や通信状況の変化などを比較できます。定期的にセキュリティアセスメントを実施する場合などに、前回のアセスメント時と比較して、各種情報がどのように変化したかを確認するのに便利な機能となっています。 資産台帳の差分分析は、次のようになります。 こちらでは、2つの期間で追加された資産（端末）は、addとして赤色で表示され、削除された端末はdelとして青色で表示されます。また、既存の端末において、利用するサービス情報（通信プロトコルや宛先ポート番号）が変化した場合には、chgとして黄色で表示されます。 マトリックス情報（MAC Vendor）の差分分析は、次のようになります。 こちらでは、2つの期間で変化のあったネットワークセグメントは黄色の枠で表示されます。例では、10.1.2.0/24のセグメントにおいて、.106のIPアドレスを利用していた端末が消失しています。 ネットワークマップの差分分析は、次のようになります。 こちらでは、2つの期間で追加されたIPアドレスを濃い緑の枠で囲んで表示しており、消失したIPアドレスを青色の枠で囲んで表示しています。こちらの例では、左上辺りに存在している、10.1.2.105、10.1.2.106、10.1.2.107のグループが2つの期間の前後で消失していることが分かります。 名前解決通信に基づく可視化 DNSなどの名前解決通信による可視化ができ、業務上不要なサイトへアクセスする端末やファイル共有サービスなどのセキュリティインシデントにつながる可能性のあるサービスを利用する端末を特定できます。 ブロードキャスト通信に基づく可視化 既存のスイッチ等へのミラーリングの設定が困難な環境向けに、可視化できる内容は限定的なものにはなりますが、ARPなどのブロードキャスト通信のみを用いたネットワーク可視化機能も作成しています。こちらは、既存スイッチのデータプレーン（データ通信用のネットワークセグメント）に余っているポートがあれば、そちらにOsecTを接続することで、流れてきたブロードキャストのパケットをOsecTがキャプチャして可視化するイメージになっています。 最後に 今回は、OTネットワークの概要、OTのセキュリティ対策とその課題に関するお話と、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの概要とネットワーク可視化機能についてご紹介しました。工場等のスマート化を推進していく上では、これまであまり検討が進められていなかった、OTのセキュリティ対策を考えることが非常に重要になってきます。 後編では、OsecTの脅威検知機能についてご紹介します。よろしければ、そちらもご覧ください。 ※2021年6月現在、OsecTの実証実験のトライアル利用者様を募集しております。無償でご利用頂けますので、国内に制御システムをお持ちの製造業・インフラ事業者の方で実際にお試ししたいという方がいらっしゃいましたら、是非 こちら からご応募頂けますと幸いです。

データプラットフォームサービス部の花川です。 普段はSDPFのメニュー開発をしていたり、社内のイベントとかに趣味で首を突っ込んでいます。 最近では Software Design 7月号のISUCON特集に社内メンバーと寄稿したりしました。 NTTコミュニケーションズの開発者ブログはこのたび NTT Communications Engineers' Blog としてリニューアルしました。 今日は「開発者ブログ」を「Engineers' Blog」としてリニューアルするきっかけについてのお話です。 開発者ブログのこれまで もともとdeveloper.ntt.comで運営されていた開発者ブログは、2015年6月頃に開始されました。 最初の記事は "開発者ブログはじめました" でした。 当時はNTT ComでAPIゲートウェイを提供し始めた頃であり、実はこの開発者ブログは弊社のAPIドキュメントやチュートリアルをまとめたサイト（NTTコミュニケーションズ デベロッパーポータル）の中のいちコンテンツとして産声を上げています。 engineers.ntt.com （2023/11/07追記：この記事の当初公開時点では、developer.ntt.comにホストされていた記事へのリンクとしていました。そのコンテンツはすべてこのブログに移転してありますので、リンク先をこのブログに張り替えてあります。以下の記事も同様です） 主なブログの役割は "APIを探そう。国内外のインデックスサービスまとめ" など、世間でのAPIの活用事例など、啓蒙としての技術詳解がメインコンテンツでした。 engineers.ntt.com 2018年1月頃から、社外イベントでの登壇の報告や、社内での勉強会紹介を記事として公開しはじめました。 それ以降、多くのエンジニアがイベント紹介や技術の解説などで寄稿をしています。 中の人目線ですが、今見ると懐かしい気持ちになるものも多いですね。 engineers.ntt.com engineers.ntt.com ありがたいことに、多くの方々に記事を見ていただけており、はてなブックマーク経由でコメントが寄せられるなどしております。 ここがつらいよ開発者ブログ さて、多くのエンジニアが寄稿し始めた開発者ブログですが、運営をしているといくつか厳しいポイントも出てきました。 開発者ブログのプラットフォームが使いづらい 前述したように、開発者ブログは弊社のAPIゲートウェイ/デベロッパーポータルというサイトのいちコンテンツという立ち位置でした。 そのため、開発者ブログの記事とデベロッパーポータルの記事は1つのCMSで管理されており、ブログ記事の執筆には大きすぎて使いづらいものでした。 また、いちコンテンツであるがゆえにデベロッパーポータルのデザインが適用されています。 「ドキュメントとして読みやすいサイト」が主な目的となっているため、開発者ブログに向いたデザインなどの適用が難しい状態となっていました。 執筆後のレビューがしづらい 2019年頃から、投稿時のルールとして、有志による相互レビューを実施しています。 これは、社内情報など出してないけないことのチェックもありますが、記事そのものをより良くすることが最大の目的です。 例えば、分かりづらい固有表現がないか、文章で読みづらい部分がないか、といった点が主なレビューポイントでした。 しかし、これまで使っていたブログのプラットフォームは下書き状態の記事は執筆者と管理者以外は閲覧できず、またレビューに使える機能もなかったため、記事のレビューがたいへんしづらかったのです。 このように、NTT Comのエンジニアが集うSlackに下書きを投稿しThreadにコメントを書くという方法でレビューをしています。 これがなかなか厳しく、定期的に「やりづらいよねえ」という話が上がっていました。 有志に負担が寄りすぎてしまう運営状況 これまで、NTT Com社内の多くのチームにおいて、記事の執筆やレビューは業務であると認められていませんでした。 そのため、社外へ情報発信する意義について理解があるチームから集まった、有志のメンバーが執筆もレビューも実施していました。 NTT Comには多くのエンジニアが存在しており、JANOGを始めとした外部での発表も多く行っています。 発表や雑誌への寄稿に対する認知・承認がある一方で、自社メディアである開発者ブログは社内の認知度が低く、エンジニア個人の意志で業務時間中に堂々と執筆に取り組むのは難しい状況でした。 新開発者ブログ、はじめます これらの問題を解決するために、デベロッパーポータルからブログだけを切りだした新開発者ブログ "NTT Communications Engineers' Blog" として再出発を切ることにしました。 詳細は今後の記事として公開する予定ですが、開発者ブログをリニューアルするにあたって、ざっくりとこんなことに取り組んで来ました。 社内デザインスタジオ KOELのメンバーの協力の下、デザインを作成 GitHubを活用したレビューと記事公開プロセスの設定と実装 社内のコミュニティ活動としてのブログ執筆やレビューの公認 記事の執筆やレビューの方針を書いたガイドブックの作成 ここまでして開発者ブログを整えるのには、大きな理由があります。 NTT Comという会社は、とても大きな会社です。 社外からは具体的になにをやってるのか分かりづらいとよく言われますが、社内にいても部署間での技術的な交流に乏しいと感じる場面も少なくありません。 しかし、社内には多くの"おもしろい"エンジニアや、技術的に高度な取り組みをしているチームが実は多くいます。 こういったエンジニアやチームが、社内だけではなく、社外に発信できる場として、このブログを整備しました。 このブログを閲覧してくれるみなさまが「へーNTT Comってこんなにおもしろいことやってるんだ〜」と思っていただければ、開発者ブログを整備したメンバーはうれしいかぎりです。 まとめ NTT Comで今までひっそりとやっていた開発者ブログをリニューアルしました。 今までイマイチだなと運用していた部分をきちんと整備し、社内のメンバーが情報発信しやすい環境をつくりました。 このリニューアルを通して、読者のみなさまが「NTT Comおもしろいことやってるじゃん」と思って頂けるような記事をどんどんと出していければと思っていますので、よろしくおねがいします! 余談ですが、すでに社内のエンジニアからいくつか記事が寄せられております。 今後の記事の更新も楽しみにしておいてください!

こんにちは、イノベーションセンターの志村です。 開発者ブログ 兼 NTTコミュニケーションズ Advent Calendar 2020 の2日目の記事です。 昨日はmahitoさんの記事、 日本企業でTGIFのような対話型イベントをやってる話 でした。 今回はThreat Intelligenceのツールである、MISPの概要とその使い方について紹介します。 この記事の要約 インテリジェンス活用のため、オープンソースのThreat Intelligence 共有プラットフォームのMISPが広く活用されている APIやモジュールによるインポート/エクスポートなど、自動化や外部連携をするための機能が充実している 「ブロックチェーン型セキュリティインテリジェンスプラットフォーム」では、MISPを活用したインテリジェンスの活用・共有を促進するプラットフォームとなっている Threat Intelligenceについて MISPの説明の前に、そもそもThreat Intelligence (セキュリティインテリジェンス、CTI: Cyber Threat Intelligence などとも呼ぶ) とは何か、についてお話しします。定義は様々ですが、かみ砕いて言ってしまえば「サイバー脅威の軽減に役立つ情報」であるといえます。 セキュリティ活動のためのThreat Intelligenceは、以下のような場面で活躍・活用できます 脆弱性マネジメント: 脆弱性の情報を収集し、パッチ対応の優先順位などを決定する セキュリティオペレーション: セキュリティアラートに関連する情報を使用し、アラートのトリアージ (対応の優先順位付け) を行う インシデントハンドリング: インシデントハンドリング中に発見されたIOC (Indicator of Compromise: 攻撃されたことを示すIPアドレスやハッシュ値などの証跡)をセキュリティインテリジェンスを用いて詳細に調査する セキュリティ意思決定: 自組織を狙う攻撃者グループの戦術、テクニック、攻撃手法 (TTPs) を収集し、不足している防御能力を把握して対処する Threat Intelligenceを活用することにより、事実に基づいたセキュリティ活動や意思決定を行うことが可能になります。 Threat Intelligenceの活用を促進するツールなどは多種ありますが、今回はその中でもオープンソースのThreat Intelligence のプラットフォームである、 MISP について紹介します MISPとは 引用: https://www.misp-project.org/features.html MISPは、Threat Intelligenceの蓄積・共有・関連づけを行うオープンソースソフトウェアです。MISPの開発はCIRCL (The Computer Incident Response Center Luxembourg: ルクセンブルグの民間部門・地方自治体・非政府組織向けのCERT) によって主導されており、機能の追加などが進められています。 MISPは公式サイトによれば「MISP - Open Source Threat Intelligence Platform & Open Standards For Threat Information Sharing」、つまりThreat Inteligenceのプラットフォームであり、またThreat Intelligence共有のオープン標準であるとされています。MISPを活用することで、Threat Intelligence を効率的に蓄積・共有し、Threat Intelligenceを活用したセキュリティオペレーションを実施することができます。 本ブログでは、MISPの利用方法や基本的な概念について紹介します。より詳細な情報などは、 MISP公式サイトの解説 、もしくは 公式サイトのトレーニング資料 やGithubの misp-training などが参考になります。 MISPを使うことで、以下のようなことが実現できます。 IOCの保存と検索 関連するインテリジェンスをイベントという形式で保存したり、保存してあるインテリジェンスを検索することができます 組織間でMISPインスタンスを接続し、インテリジェンスを共有する 自動的にMISP上の情報を共有することができます。共有していい情報とそうでない情報を区別することも可能です セキュリティアプライアンスで活用可能なデータ形式でのエクスポート suricataなど、セキュリティアプライアンスに投入可能な形式でインテリジェンスをエクスポートすることができます イベント間の相関分析 IPアドレスやドメイン名、ハッシュ値などが共通するイベントがあった場合、そのイベントと関連付けることができます。これによりアラート対応時に関連する情報を簡単に参照することなどが可能になります MISPの概要 MISPの基本的な構成単位などについて説明します。 Event MISPはEvent (イベント) という単位でインテリジェンスを管理します。 インシデント、マルウェア、インテリジェンスレポートなどを1つのイベントとして管理します。 イベントの例 Attribute 各イベントに紐づく具体的なIOC (IPアドレス、ドメインなど) などを保存する単位として、Attribute (アトリビュート) があります。 イベントとアトリビュートは1対多の関係になっており、1つのイベントに複数のアトリビュートが属する形になっています。 例として、あるインシデントを1つのイベントとして作成した場合、そのインシデントで発見されたIPアドレスやドメインなどをアトリビュートとしてイベント配下に作成します。 アトリビュートにはカテゴリーとタイプが存在します。例えば Network activity というカテゴリーには　 domain , ip-src , ip-dst などのタイプが存在します。 ユーザは適切なアトリビュートのカテゴリーとタイプを選択し、イベントに追加していきます。 アトリビュートの例 Object Object (オブジェクト) は、アトリビュートの組み合わせによって構成され、アトリビュート間の関連性を表すことができるものです。 例えば domain-ip というオブジェクトは domain , ip-dst , port などのアトリビュートを組み合わせ、観測されたドメイン/IPを表現するためのオブジェクトになります。 オブジェクトの例 オブジェクトは他のアトリビュート、オブジェクトとの relationships (リレーションシップ) を追加することができるのも大きな特徴です。これにより、MISPオブジェクトの背景情報を追加することが可能になります。 例えば communicates-with というリレーションシップをドメインのオブジェクト間に作成すれば、あるオブジェクト(例: マルウェアを表すオブジェクト) から別のオブジェクト(例ネットワークホストを表すオブジェクト)に通信が発生したことをMISPイベント上で表現することができます。 Tag Tag (タグ) はイベントやオブジェクトに付与することができる、イベント間の関連づけを行うためのものです。 タグを使うことで、イベントやオブジェクト間の関連性をMISP上で表すことができます。 Taxonomy Taxonomy (タクソノミー) は、情報のタグ付けや整理を行うための、共通のタグのライブラリです。タクソノミーはタグとして表現されます。 MISP間でイベントを共有する際、各インスタンスが独自のタグで管理を行うと、タグの意味するとことが分からずに混乱を生じます。 タクソノミーを使うことで、複数のインスタンス間で共通のタグを利用でき、円滑に情報共有することができます。 タクソノミーは、Githubの misp-taxonomy で定義されています。例えばTLP (Traffic Light Protocol)のタクソノミーを使うことで、情報の公開可能範囲をタグで規定することができます。 Galaxy Galaxy (ギャラクシー) は、イベントやアトリビュートに付与することができる、cluster (クラスター) と呼ばれる巨大なオブジェクトです。クラスターは複数のkey-value形式の要素を持ち、タクソノミーなどより多くの情報を付与することができます。 ギャラクシーはタクソノミー同様Githubのmisp-galaxy]( https://github.com/MISP/misp-galaxy )で定義されています。定義済みのギャラクシーには攻撃者グループの情報やマルウェアなどがあり、ギャラクシーを使うことでイベントやアトリビュートを補完することができます。 MISPのインストール方法 MISPを利用するために、MISPをインストールする方法について紹介します。 MISPのインストール方法は、 MISP公式ページ に記載されており、いくつかの選択肢があります。 公式のインストールガイドを使う場合 https://github.com/MISP/misp-taxonomies 基本的には自分が使用するOSのインストールガイドに従うことで、MISPのインストールが可能です。 例として、Ubuntu 18.04の場合は以下のコマンドでインストール可能です。 # インストールスクリプトのダウンロード wget -O /tmp/INSTALL.sh https://raw.githubusercontent.com/MISP/MISP/2.4/INSTALL/INSTALL.sh # インストールスクリプトの実行 bash /tmp/INSTALL.sh Dockerイメージを使う場合 MISPのdockerイメージはいくつか 公式サイト で紹介されておりますが、現在は docker-misp を利用するのが良いと思われます。 MISPの使い方の紹介 MISPのUIの使い方を簡単に紹介します。 Feedからのデータの入手 MISPをインストールした段階では、イベントは空の状態です。Feedと呼ばれる機能を使うと、イベントを外部から入手することが可能になります。 MISPはデフォルトでフィードの設定がいくつか存在しており、それを有効化することでOSINT (open source intelligence) などを入手することができます。 画面上部のメニューバーから、"Sync Actions" -> "List Feeds" とクリックし、フィードを設定画面に入ります。その後、有効にしたいフィード ("CIRCL OSINT Feed" など) の列の右端の "Actions" の項目のEditマークをクリックします。 そして "Enable" をクリックしてフィードを有効にし、ページ下の"Edit" をクリックして設定を完了します。 すると"Actions" の項目に "Fetch all events" というボタンが表示されるのでクリックすると、有効にしたフィードのイベントをMISPに取り込むことができます。 フィードはデフォルトで存在しているもの以外にも、自分で設定することも可能です。 イベントの閲覧 イベントの一覧の表示は、画面上部メニューバー左端の "Home" をクリックするか、"Event Actions" -> "List Events" と選択することで可能です。 イベント一覧から各イベントの画面に入るには、 "Id" の列に表示されているイベントIDの数値をクリックします。 各イベントの画面では、Evnetの各種情報などを閲覧できます。また画面下部にある + , - と書かれているボタンを押しますと、各項目の表示/非表示が切り替えられます。 例として "Correlation graph" の左の "+" をクリックすると、イベント間の相関分析のグラフを表示することができます。 Correlation graphでは、共通するアトリビュートを持つイベントを表示して関連性を調査することができます。 イベント・アトリビュートの作成 MISPのイベント・アトリビュートの作成方法について簡単に紹介します。詳細な説明は、MISPドキュメントの クイックスタートページ などを参照してください。 イベントの作成 MISPにデータを投入するためには、最初にイベントを作成する必要があります。 MISPのホーム画面の左側の "Add Event" を選択するか、上のメニューバーにある "Event Actions" -> "Add Event" を選択することでイベントの作成画面に入ることができます。 続いてイベントの情報を入力します。 Date: イベントの日付を入力します。 Distribution: MISPの機能でイベントが共有される範囲を選択します。 Threat Level: イベント作成者が考える、このイベントの脅威度を選択します。 Analysis: このイベントの解析段階を選択します。 Event info: イベントの概要を入力します。 Extends Event: 継承するイベントのID、もしくはUUIDを指定することでそのイベントを継承することができます。 アトリビュートの作成 イベントを作成すると、そのイベントに紐づくアトリビュートを作成可能になります。 イベント画面の左側の "Add Attribute" をクリックすることでアトリビュートの作成画面に入ることができます。 続いてアトリビュートの情報を入力します。 Category: "Network Activity"、"Antivirus Detection" など、アトリビュートの情報のカテゴリを選択します。 Type: アトリビュートの種類を選択します。Categoryごとに選択できるTypeが決まっています。 (Network Activity なら "ip-src", "domain"など) Distribution: このアトリビュートの公開範囲を選択します。デフォルトではイベントの公開範囲と同じになります。 Value: アトリビュートの具体的な値を入力します。 以上の作業により、イベントとそれに紐づくアトリビュートを作成することができます。 より多くのアトリビュートを一度に入力したい場合は、イベント画面左側の "Populate from" を選択することで、 "Freetext import" などの一括投入機能を使うことができます。 Freetext importは、自由なテキスト形式でIOCを投入できる機能です。IOCをテキスト形式で入力すると、自動的にカテゴリーとタイプを解釈して一括で入力が可能になります。 自動化 MISP はイベントの検索・取得や、イベントの新規作成などの各種操作を可能とする、REST API を提供しています。 REST APIの操作方法などは、 公式ドキュメント などに記載されています。 PyMISPについて REST APIを簡単に使用する方法として、公式のPythonライブラリーである PyMISP が提供されています。 PyMISPを利用することで、イベント/アトリビュートの作成や検索、タグ付けなどの操作をPythonを利用して自動化することができます。 PyMISPの利用方法は、 公式ドキュメント や PyMISPの Tutorial などが参考になります。 PyMISPの利用方法 MISPの操作には、pymispインスタンスを作成します。 from pymisp import PyMISP # アクセスURLの設定 MISP_URL = "https://misp.exmaple.com" # APIキーの設定 MISP_KEY = "YOURMISPKEY" # pymispインスタンスの作成 misp = PyMISP(url=MISP_URL, key=MISP_KEY, ssl=False, debug=False) イベント・アトリビュートの作成 イベントやアトリビュートの作成をする際は、 PyMISP.add_event を使用してイベントを作成した後にアトリビュートを追加します。 from pymisp import MISPEvent # イベントの作成 event_obj = MISPEvent() event_obj.info = 'This is my new MISP event' # Required event_obj.distribution = 0 # Optional, defaults to MISP.default_event_distribution in MISP config event_obj.threat_level_id = 2 # Optional, defaults to MISP.default_event_threat_level in MISP config event_obj.analysis = 1 # Optional, defaults to 0 (initial analysis) # オブジェクトの追加 event_obj.add_attribute('ip-dst', '192.168.10.1') # MISPインスタンスへの追加 misp.add_event(event_obj) イベント・アトリビュートの検索 文字列などで検索する場合は PyMISP.search を利用します。 例として、 192.0.2.1 という文字列を含むイベントを検索したい場合は以下のようになります r = misp.search(controller='events', value='192.0.2.1') イベントではなく、アトリビュートを検索することも可能です。 r = misp.search(controller='attributes', value='192.0.2.1') MISP活用の注意点 MISP活用していて注意すべき点について紹介します。ただ常に当てはまるわけではなく、意見には個人差がある旨をご了承ください。 イベントを肥大化させすぎない MISPでは、既存のMISPイベントにもアトリビュートを追加することができます。 しかし既存のMISPイベントにアトリビュートを追加し続けると、古い情報と新しい情報が混在するイベントになってしまいます。 インテリジェンスには鮮度があり、IPアドレスやドメインなどはすぐに陳腐化するため、古い情報を参照し続けることは誤検知などの原因になります。 1つのアラートの調査結果を1つのMISP イベントとして作成するなど、適切にイベントを分けるのが重要です。 イベント間の関連付けをタグなどで行うと、データの関連を示しつつイベントを分割することができます。 タグを積極的に活用する タグはイベントの概要を把握が容易になる、同一のタグのイベントなどを容易に検索できるなど、多くのメリットがあります。 MISPではコミュニティ主導でタクソノミーやギャラクシーの更新などが行われています。積極的に活用して、マルウェアファミリーなどの情報を付加するのが望ましいです。 またAPIを用いて自動化の際に、タグの値によって処理を変える、といった使い方も可能です。 情報ソースを残す このイベントは何を意味しているのかなどの背景情報を残すことは重要です。 例えばWeb上の情報などを基にイベントを作成する場合、そのページへのリンクともにPDFを添付するなど情報ソースを残す取り組みをするとよいでしょう。 まとめ 本日は、オープンソースのThreat Intelligence 共有プラットフォームのMISPを紹介しました。 MISPはコミュニティベースで開発が進められており、今も新しい機能が追加され続けています。 MISPを使用することで、Threat Intelligenceを使用するオペレーションの高度化・実現をすることが可能になります。 宣伝 最後に宣伝を。10月にニュースリリースで公開された 「ブロックチェーン型セキュリティ情報流通フレームワーク」 では、MISPを利用して脅威情報の共有・高度化を可能にするプラットフォームとなっています。 MISPインスタンスを接続していなくてもインテリジェンスを共有できるなどの特徴を備えています。 実証実験を実施中なので、ご興味ある方はニュースリリースの問い合わせフォームよりお問い合わせください。 https://www.ntt.com/about-us/press-releases/news/article/2020/1006_2.html 最後に 明日は yuki_uchida さんの 「 WebSocketの次の技術！？WebTransportについての解説とチュートリアル 」です。お楽しみに。

こんにちは、インシデントレスポンスサービス担当の濱崎です。今回は日本時間で 2020/9/12 10:00 ～ 10/24 10:00 に開催された Reverse Engineering の腕を競う大会、Flare-On 7 Challenge に参加したので、その内容と結果を紹介したいと思います。 Flare-On Challenge とは Flare-On Challenge は FireEye 社が毎年主催している Reverse Engineering に特化した Capture The Flag(CTF) 形式のセキュリティコンテストです。2014年から毎年 8～10 月の期間で開催されており、今年で7回目なので Flare-On 7 Challenge と呼ばれています。他の CTF に比べ次のような特徴があります。 多くの問題が Windows で動作するソフトウェアで構成されている FireEye 社が業務で実際に解析したマルウェアにインスピレーションを得て問題を作成しており、数ある CTF の中でも実践的な問題が多い 毎年 10～12 問出題され、一つ問題を解くと次の問題が提供される 開催期間は 6 週間と長い 多くの CTF は Linux で動作するソフトウェアを中心に構成されていると思います。また、マルウェア解析というタスクを意識した問題はそんなに多くないかと思います。そのため、Windows マルウェア解析の技術研鑽や腕試しをしたい人にはうってつけの CTF です。また、一般的なCTFは土日の間の24時間、または48時間で開催されますが、Flare-On Challenge は6週間と長い期間開催されるため、隙間時間を利用して取り組むことができます。土日にまとまった時間が取れない人にも優しい開催スケジュールとなっています。 私の普段の業務はマルウェア解析ではないのですが、趣味で楽しんでいることもあり今年は腕試しに参加してみることにしました。 チャレンジ結果 今年は計11問出題され、参加者は全部で5,668人。全問正解者は279人（全体の4.92%）という結果でした。その中で私は9問解くことができました。正直、開催前は6問くらい解ければいいなあと思ったのですが、思った以上に解けましたし、何より問題を解く中で新しい技術や知識が身についたので非常に満足しています。本業のディスクフォレンジック業務に役立つものもあり、業務の品質向上につながるものであったと感じています。ただ、10問目はかなり時間を使ったのですが解けず、まだまだ未熟だなと感じたのも正直なところです。ちなみに、Twitter などの評判を見ると、毎年最後の2問は一段とレベルがあがるそうです。見事にその壁に阻まれたことを知り、非常に悔しい気持ちでいっぱいです。臥薪嘗胆、来年は突破すると心に誓いました。 　 Flare-On Challenge Score 　 各問題の正答者数（1問以上解けた人は3,574/5,668人） 出典： https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html FireEye社のブログには正答者に関する各種統計値が載っていますが、個人的に興味深かったのは全問解けた人が所属する国についての集計値です。（所属国の入力は任意ですしバリデーションもないので、どこまで信用できるかは不明ではあります） 　 全問正答者の所属国の集計値 出典： https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html アメリカが見事に1位に輝いていますが、これには驚きはありません。驚いたのは、2位のシンガポールです。シンガポールの人口は570万人ほどだそうです。アメリカは約3.2億人ですので、シンガポールのセキュリティエンジニアのレベルの高さを感じさせます。また、3位ロシア、5位イスラエル、7位ベトナム、8位中国、10位ウクライナなど、サイバーセキュリティ関連のニュースで話題になる傾向が高い国は、比較的上位に位置しているように思えます。この結果は、国としてのサイバーセキュリティへの力を入れ具合、という指標になっているのかもしれません。ちなみに日本は全問正答者1名です。日本もサイバーセキュリティに力を入れていますし、多くの素晴らしい取り組みを行っていますが、こういった大会・イベントでのプレゼンスを上げたいと思うのは私だけではないと思います。 出題内容概要 はじめは WriteUp(=解法) を書こうかと思いましたが、FireEye 社公式 WriteUp が素晴らしいのでそちらを参照いただくとして、ここでは全11問について、その内容を一言でまとめてみます。一部解法のエッセンスを含みますのでご注意ください。 challnege # challenge title 概要 challenge1 fidler ゲームのクラック問題（python ソースコード付き） challenge2 garbage.exe 壊れた packed binary の修復問題（フォレンジックなどで復元した、データの一部が壊れてしまったバイナリを想定？） challenge3 Wednesday (mydude.exe) ゲームのクラック問題（ソースコード無し） challenge4 report.xls VBA stomping された xls の解析 challenge5 TKApp.tpk Tizen OS という Samsung の TV, wearable device などで使用されている OS で動作するアプリケーションパッケージ。ただ、やることは、 .NET アプリケーションの解析 challenge6 codeit.exe Autoit マルウェアの解析からインスピレーションを得た問題。解析自体は容易だが、flag の特定にクセがあり、個人的には難問だった challenge7 re_crowd.pcapng pcap に含まれる IIS の RCE 脆弱性(CVE-2017-7269)攻撃ペイロードの解析 challenge8 Aardvark ゲームのクラック問題。WSL 環境のみで動くことを特定する必要あり。 challenge9 crackinstaller.exe ソフトウェアのクラック問題。様々な暗号方式＋COM Objectの理解＋カーネルドライバの理解など、幅広い知識を求められる問題。個人的には最高に好きな問題。 challenge10 break Linux ELFバイナリ。子プロセス、孫プロセスが親プロセスを ptrace することで RPC 通信を実現している。ptrace を使っているのでデバッグが難しく厄介。解けなかった。 challenge11 Rabbit Hole チャレンジできなかった。かなり難問らしい。Gozi V3 を模倣しているとのこと。 個人的に最も好きなのは challenge9 の crackinstaller.exe です。この問題は、様々な技術要素が盛りだくさんで本当に勉強になりました。知らない知識や知っていてもあまり触れたことがない技術要素が詰まっているこの問題は大好きです。少しだけ紹介します。 この問題は、ソフトウェアのクラックをモチーフにしており、registry に正しい password が設定された状態でプログラムを特定の方法で動かすと flag を取得することができます。この password が何なのか、そして flag を取得するためのプログラムの動かし方は何なのか、を探す問題になります。 最初に渡される PE ファイルに、3つの別の PE ファイルが暗号化された状態で含まれています。一部はドロップし、一部はメモリ内で実行されます。 任意のユーザコードをカーネルモードで実行可能にする機能を持つ、正当な署名を持つ既知のカーネルドライバ 署名なしのカスタムカーネルドライバで、1の署名有カーネルドライバを通して実行される COM Server DLL 1,2はある文字列の SHA256 ハッシュを key とした ChaCha20 暗号方式で暗号化されており、3はシンプルな XOR で暗号化されています。 　 SHA256 hash 生成(Base64にも見えるがSHA256） 　 ChaCha20 復号処理 password については、2のカスタムカーネルドライバ内に ChaCha20 で暗号化された状態で保存されており、同ドライバ内の処理で復号されます。これを特定するにはカーネルドライバ特有の API や Registry Filter Driver の知識が必要です。また、その password は regedit などの一般的な viewer では閲覧できない Registry Class Type Strings に設定されるため、この辺の知識もあるとスムーズな解析が可能でした。 flag については、上記の方法で取得した password を HKEY_CLASSES_ROOT\CLSID\{CEEACC6E-CCB2-4C4F-BCF6-D2176037A9A7}\Config\Password に設定後、前述の 3. COM Server DLL の機能を呼び出せば取得できます。そのためには COM Class IID の特定と、それを呼び出す COM プログラムを書く必要があります。私は COM Class IID の特定を行う流れでそのまま静的解析をすることで flag を取得しました。その際、password を key とした RC4 暗号方式で flag を復号する処理があるため、RC4 の知識も必要になりました。他にも、AES 暗号方式で暗号化されている部分もあります。 　 RC4 Key-scheduling algorithm (KSA) このように、シンプルな XOR, RC4, ChaCha20, AES などの様々な暗号方式が何度も使用されています。そして、複数のバイナリが複雑に絡み合っていたり、カーネルドライバが絡んでくるため、動的解析もやりにくいものでした。結果として静的解析による暗号データ復号のとても良い訓練になりました。 ただ、カーネルデバッグの環境が整っている人は、動的解析でやってしまえば暗号方式特定作業は不要だったかもしれません。私は勉強したことがある程度で慣れてもないし、環境も用意していなかったので静的解析するしかなかった点は、経験不足を感じたところです。 最後に 私個人は challenge 9 でも十分難しく感じましたが、 SNS 上の世界のマルウェア解析者の感想では challenge 10, 11 への反応が非常に多く、まだまだレベルが追いついていないように感じました。次回は全問正解を目指したいと思いますし、日本人のプレゼンスも向上すると良いなと思っています。 This year’s winners are truly the elite of the elite! https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html エリート中のエリートを目指して、皆さんも一緒に挑戦しませんか？