技術情報 の記事一覧

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、CFPセッション「k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会社　技術部プラットフォームグループ シニアエンジニア/SRE菅原 千晶（@ch11aki） 「k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話」 https://speakerdeck.com/ch1aki/k8s-operatordeyun-yong-fu-dan-jian-and-haiburitudokuraudonokosutozui-shi-hua-wositahua 「k8s Operatorで運用負荷軽減とハイブリッドクラウドのコスト最適化をした話」と題しまして、GMOペパボ株式会社 菅原 千晶が発表します。 改めまして、GMOペパボの菅原 千晶と申します。弊社ではあだ名文化があり、社内では「akichan」と呼ばれています。私が所属する技術部プラットフォームグループは、特定のサービスの事業部には所属しない、サービス横断のSRE組織です。サービス運用の効率化、サービスレベル目標設定や、それを達成できるようにするための支援などを行っています。私の簡単な経歴としましては、2018年3月に未経験者向け研修付き採用制度の「ペパボカレッジ」枠で入社しました。昨年までは主にネットショップ作成サービスのカラーミーショップの運営に携わり、k8sの導入支援やGitOpsの推進などを行ってきました。現在はハンドメイドマーケットサービスのminneに注力し、サービスの信頼性とエンジニアの生産性を向上させるあらゆることに取り組んでいます。最近ではArgo Rollouts導入によるプログレッシブデリバリーの実現や、CDNコストの削減、RailsアプリのN+1問題の解消などを行いました。 本日お話しするのは、タイトルにある通り私が担当するminneの運用において、k8s Operatorを開発して運用課題を解消した話です。まず、minneのインフラ構成とそこにあった運用課題について説明します。そして、そこで得られたk8s Operatorで運用課題を解決することのメリットについて説明します。Operatorの詳細な実装方法などについては時間の都合上触れられませんので、発表を聞いてOperatorの開発をやってみたいと思った方は、ご紹介する書籍やWebページ等をご覧ください。 Section1│minneのインフラ構成 それでは、まずminneのインフラ構成から説明いたします。私が担当するminneは、ハンドメイド作品をインターネット上で販売・購入できる国内最大級のハンドメイドマーケットです。数値でみると、作家・ブランド数は80万件以上、作品数は1,500万点以上、モバイルアプリのダウンロード数は1,300万件以上の大規模なサービスとなっています。 そんなminneのインフラは、AWSとプライベートクラウドのハイブリッドクラウドで構成されています。ペパボではNyahと呼ばれるOpenStackベースのプライベートクラウドを持っています。AWSではEKS、Nyahではself-hostedのk8sクラスタを運用しており、ほとんどのアプリケーションはその上で動作しています。それぞれのk8sクラスタで動作しているアプリケーションは同一のものです。NyahはAWS Direct ConnectでAWSへ専用線接続されているため、相互の環境は透過的にアクセス可能になっています。例えばステートフルなDBやCache等はAWSのマネージドサービスを利用していますが、プライベートクラウド環境からもアクセス可能になっています。また、AWSだけでサービス持続可能なように設計されています。 プライベートクラウドNyahについてもう少しご説明します。Nyahの最大の長所は安価であるということです。同程度のスペックのEC2 instanceを利用するのと比較して、利用コストが数分の一で済みます。しかし一方で短所もあり、パブリッククラウドに比べるとスケーラビリティに制約があります。ある程度の余剰はありますが、爆発的なリソース需要の急増には対応することが難しいです。 minneでパブリックとプライベートのクラウドでハイブリッドクラウドの構成を選択している理由としてはいくつかあります。1つはプライベートクラウド自体の障害の対策です。社内で運用しているサービスのため、時には障害が発生し利用できなくなる可能性もあります。その際のリスクを考慮しています。minneではプライベートクラウド側だけにしかないリソースは基本存在せず、万が一の時には前述の通りAWS側だけでサービス継続が可能になっています。 2つ目の理由としては、安価なプライベートクラウドのコンピューティングリソースを最大限に活かしつつ、部分的にマネージドサービスを利用することで運用負荷を軽減できるからです。運用負荷の高いDBやCacheなどはRDSやElastiCacheなどのAWSのマネージドサービスを利用して、ステートレスなリソースに関してはプライベートクラウドを活用しています。 3つ目の理由としては、先ほど述べたプライベートクラウドの短所であるスケーリングの制約をカバーするためです。プライベートクラウド内のスケーリングで間に合わない場合は、Route53の加重レコードでAWS環境へ向くトラフィックの割合を調整し、プライベートクラウドで受けるリクエスト数を抑えます。 Section2│運用上の課題 続いてminneにあった運用上の課題について説明します。先ほど述べたプライベートクラウド内のリソースで間に合わない時にAWSへリクエストをオフロードする運用は、実は都度人力で行っていました。具体的には、割引クーポンやテレビ放映などのリクエストが急増するようなイベントがある度に、次のような作業を行っていました。まず、過去の実績の中から似たような事例を探し、ピーク時のリクエスト数を予測します。次に、過去のキャンペーンやテレビ放映時のレスポンスタイムや負荷状況と照らし合わせて、プライベートクラウド内のリソースだけで間に合うかどうかを試算し、リクエストをオフロードするかを判断します。そして、ピーク時にプライベートクラウド環境のキャパシティオーバーとならないよう、AWS側へオフロードする最適な加重を計算して事前に設定しておきます。ピークが過ぎリクエストが落ち着いたら加重設定を通常の割合に戻します。右のグラフはこの操作を行った際のそれぞれのクラウド環境で処理するリクエスト数の変化のイメージです。プライベートクラウドNyahで2,000リクエストまで許容できるとした時、最大3,000リクエストが予測された場合には、Nyah側へのリクエスト数が2,000リクエスト以下に収まるよう、AWS側で4割のリクエストを処理するよう加重を調整しています。ピークが過ぎた後加重設定を戻しています。 この運用の問題点としては、専門性が高く限られたメンバーしか実施が難しいため、運用作業がスケールしないことが挙げられます。また、実際より需要を多く見積もってしまった場合や、翌日や休み明けに加重設定を戻すまでのアイドルタイムの間、無駄にパブリッククラウドのリソースを利用している状態になっており、クラウドのコスト的に最適な状態であるといえません。さらには、誤って需要を少なく見積もってしまった場合、リソースが足りずレスポンスの遅延などが発生し、サービス障害となってしまう可能性があります。 この運用課題を解決するため、理想状態として自動でリクエスト数に応じた最適な加重が設定されることを目指し取り組みました。実は弊社サービスのSUZURIもminne同様ハイブリッドクラウドで動作して同様の課題を抱えており、LambdaやCloudWatch等のAWSのサービスを活用した先行事例がありました。これと同じ仕組みをminneでも構築することが考えられましたが、minneやSUZURI以外のハイブリッドクラウド構成をとる社内の他のサービスで個別にこれらの仕組みを構築運用していくのは非効率になると考え、全社統一での汎用的な仕組みで解決する道を探りました。 Section3│k8s Operatorによる自動リクエストオフロードの実現 そんな時に思いついたのが、k8s Operatorでこの課題を解決する方法でした。k8s Operatorとは、カスタムリソースを用いてk8sを拡張するコンセプトのことです。例えばDeployment Resourceに対するDeployment ControllerがReplicaSetを管理するように、独自に定義したカスタムリソースに対してCustom Controllerとして任意の動作を行います。有名なOperatorの例としてはカスタムリソースでPrometheusを管理するPrometheus Operatorや、AWSの各種リソースをカスタムリソースで管理できる AWS Controllers for Kubernetesなどがあります。またOperatorはk8sのコア・コンセプトのReconciliation Loopの仕組みに準拠して動作しています。 Reconciliation Loopとは、システムの現在の状態を観察比較して、現在の状態が理想の状態に一致するように変更するということを繰り返し行うループ処理のことです。ReplicaSet Controllerを例にとると、Replica数が3に設定されている時、管理するPodが何かしらの理由によって1つ減ったとしても、Replica数=3を維持するために新しく1つPodを追加するといったような具合です。k8sの様々なControllerはこのReconciliation Loopをもとに設計され動作しており、k8sの特徴である宣言的な設定はこの考えのもとに実現されています。 今回、リクエストオフロードの運用課題解決をOperatorで実装した理由の1つは、プライベートクラウドのキャパシティ不足に陥らないようにプライベートクラウドのリクエスト数を一定以下に抑えるために行うリクエスト数の確認、最適な加重の計算、加重設定の更新の操作の自動化を考えた際、まさに定義された理想状態に収束させるReconciliation Loopのパターンにマッチしそうと考えたからです。また、先ほど紹介した先行事例のSUZURIの件では、AWSのサービスをフル活用していましたが、Operatorとして実装できれば動作プラットフォームがk8sとなるため、クラウドベンダーなどの依存を減らすことができ、その他サービス事業部での活用の幅が広がりそうとも考えました。  Operatorの開発にはkubebuilderというフレームワークが提供されており、実装の型がある程度決まっています。kubebuilderによるOperatorの実装はカスタムリソースの設計とReconcile処理実装に大きく分かれています。カスタムリソースの設計について私はまず前述のプライベートクラウドのキャパシティ不足に陥らないように、プライベートクラウドのリクエスト数を一定以下に抑えるリクエスト数の確認、最適な加重の計算、加重設定の更新の操作を細かく分解しReconcile処理に必要な要素の整理をしてカスタムリソースの型を決定しました。例えば、リクエスト数を知るため、Prometheusからメトリクスを取得する必要があるので、 Prometheusの接続先と認証情報とクエリのフィールドが必要といったような具合です。次に、定義したカスタムリソースの状態を維持するようなReconcile処理を実装していきました。この実装に関しては、既存の多種多様なカスタムコントローラーを参考にしました。例えばPrometheusからメトリクスを取得するような処理はプログレッシブデリバリーコントローラーのArgo Rolloutsに似たような実装があるため参考にしました。 そして完成したのが、Rebalancerと名付けたOperatorです。これは、指定したポリシーに基づいて外部のメトリクスを参照してターゲットの加重を自動で調整します。現在はターゲットとしてRoute53、メトリクスとしてPrometheus、ポリシーはメトリクスが指定した値を維持するように最適値を算出するターゲット追従ポリシーのみに対応しています。弊社内の他のサービス事業部での活用を広げられるよう、ターゲットとしてPowerDNSやAWS ALBの加重ターゲットグループ、メトリクスとしてCloudWatch、Mackerel等への対応を考えています。 こちらが、Rebalanceカスタムリソースのサンプルです。プライベートクラウドでのリクエスト数が一定以下になるよう、AWS環境へ向く加重レコードのweight数を調整する場合の設定です。 簡単に説明するとmetricsフィールドに定義したPrometheusに定期的にクエリを発行して、現在のプライベートクラウド側のリクエスト数を取得しています。policyフィールドで選択した戦略がメトリクスとプライベートクラウド側のレコードのweight数をもとに最適な加重設定を計算します。得られた最適な加重設定を、targetに指定したレコードに設定します。例えばプライベートクラウド側の加重設定が10で、リクエスト数を1,000以下に抑えたい設定の場合、2,000リクエストが来ていたら10:10、3,000リクエストが来ていたら10:20といったように最適なweightを調整します。 このOperatorを作成したことで、月に複数回あった人力でのリクエストオフロード運用が0件になりました。基本的には、Operatorによる自動調整に任せておけば適切にオフロードされています。また、オフロード設定が最適化され、必要ない時にはAWS側へのオフロードが自動で無効に再設定されるため、アイドルタイムに無駄に利用していたAWS側のリソースが約20%削減されました。さらに、汎用的な設計でOperatorとして実装したことで、全社統一の仕組みで自動オフロード機能を提供可能になりました。GMOペパボでは便利ツールが動作する社内共通のk8sクラスタがあり、そこでマネージドで提供することで、カスタムリソースを書けばすぐ利用できるようになります。また、セキュリティ的な要件で、外部からのAPIの操作が難しいような場合でも、サービス事業部管理のクラスタにOperatorをインストールすることでも利用できます。 今回、Operatorによる運用課題解決を実施した結果、複数のメリットがあることが分かりました。1つは、当初の目論見通りクラウドベンダー依存が少なく可搬性が高いことです。システムの設計をする際に、この仕組みによって設計の制約が生まれる可能性が低くなると考えます。また、カスタムリソースのバリデーションはkubebuilderを用いることで簡単に実装できたため、コアなロジックの実装に集中できました。バリデーションがあると利用者は安心して利用することができ、運用者目線からすると設定の説明等に関するコミュニケーションコストも減らせるといったメリットを、低コストで享受できました。さらに、自動化の設定はカスタムリソースとなりk8sのmanifestとして管理されるため、その管理やデプロイ方法は既存のk8sの管理と同じ方法をとることができるのもメリットでした。新たなツールを導入した時に考えないといけない設定の管理回りの考慮を減らすことができました。また、kubebuilderを用いることで実装の型がある程度決まるので、チームメンバーがコードの内容をキャッチアップしやすいといったメリットもありました。 Section4│まとめ 最後にまとめです。この発表では、まずminneにおいて繰り返し発生する運用作業の削減とプライベートクラウドのコストメリットを生かすため、自動でAWSにトラフィックをオフロードしたい課題があったことを説明しました。その実現のため、汎用的でベンダー依存が少なそうなk8s Operatorを作成する方法を選びました。これによって、月数回発生していた運用作業を0件にすることと、アイドルタイムに無駄に利用していたAWS側のリソースを20%削減する効果が得られました。また、これを通して分かった、k8s Operatorで運用作業の自動化を実現する様々なメリットがあったことをご紹介しました。今後、運用課題解決の方法の選択肢の1つとして、Operatorを開発する選択肢をぜひ加えてみてください。 発表は以上となります。ありがとうございました。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/U0_hbrJ44wk

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、スポンサーセッション「Dynamic VM Scheduling in OpenStack」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会社　技術基盤チーム シニア・プリンシパル山下 和彦（＠pyama86） 「Dynamic VM Scheduling in OpenStack」 はじめに https://speakerdeck.com/pyama86/dynamic-vm-scheduling-in-openstack GMOインターネットグループのスポンサーセッションで、GMOペパボの山下から、「Dynamic VM Scheduling in OpenStack」というテーマでお話しさせていただきます。 最初に軽く自己紹介をいたしますと、私はGMOペパボの技術基盤チームというところで、シニア・プリンシパルとして活動している山下と申します。TwitterやGitHubは「＠pyama86」というアカウントでやっております。個人でずっと面倒を見ているプロダクトがありまして、STNSというものをやっていて、これは何かというと、旧来LDAPとかMySQL、もしくは/etc/passwdなどで管理されていたLinuxのユーザーやグループを、HTTPベースのJSON APIで名前解決できるというプロダクトです。 続いて、我々GMOペパボの紹介を簡単にさせていただきます。GMOペパボは、ホスティングやハンドメイド、あとはECとか、いろいろな事業領域にわたってサービスを提供している会社です。もともと画面左上にあります「LOLIPOP!」というレンタルサーバーサービスから始まった会社で、そこから派生してECやハンドメイド、最近だとCMをご覧になった方もいらっしゃるかもしれませんが、「SUZURI」という好きなアイテムを自分の画像で作れるサービスもやっております。 CNDTは私も何度か参加したことがありますが、久しぶりにオフライン開催で最高だなと思っている次第です。ただ、これは録画で、今日は10月19日水曜日の14:15で、GMOインターネットグループのパートナーの皆さんと一緒に楽しくお喋りしたり、掛け合いしたりしているのは私だけで、なんか恥ずかしい感じで録画をしています。 今日話すことは、最初に我々のインフラ構成をご説明して、そのあとに発生した問題に触れて、それを解決した話と、あと最後にまとめていくのと時間が余れば結婚における大事なこと42選についてもお話ししていこうと思っています。 ペパボのインフラ構成 ペパボのインフラ構成をざっくり紹介します。我々は大きく4つのインフラがありまして、1つはOpenStack、これはオンプレミスのデータセンターで、物理サーバー80台、その上でVMが1,000台ほど動いています。ここは先ほどご紹介した会社のあらゆるサービスが共用して使っている環境になります。続いてBaremetalサーバー、これはホスティング系のサービスを中心に、物理サーバーの上へそのままOSをインストールして使っています。AWSはOpenStackの待機系としてEKSを使っているほか、データストアのRDSとかElasticxxx系とかのサービスを中心に利用しています。GCPは、一番はBigQuaryでデータ解析に使っていますが、あとは一部の事業においてはOpenStackの待機系としてGKEを使っていたりします。OpenStackの上でKubarnetesを最近動かしているのが主にあって、OpenStackについては右の図で説明すると、Baremetalサーバーが並んでいて、その上にOpenStackを構築してあげて、そのOpenStackで作成したVMの上にKubarnetesを構築してその上にContainerを置く、という感じです。Kubarnetesについても自社でエンジンを開発していて、そのエンジンを用いてKubarnetesを構築したりとか、保守運用をしたりとか、そんな感じで運用しています。 CPU Stealに起因した隣人問題 今回の主題となるノイジーネイバー問題についてご紹介していこうと思います。今回発生したノイジーネイバー問題は、CPU Stealに起因したものでした。これがなぜ起きるかというと、最初に紹介した我々のいくつかのサービス、基本的には国内で事業を展開しておりまして、国内で事業を展開しているとだいたいインターネットサービスはピークタイムが似通ってきます。お昼休みの時間とか帰宅したあとの夕食の時間帯といった感じで、ECサービスやハンドメイドサービスのピークタイムがめちゃめちゃかぶってしまう。我々のサービスはOpenStackの上でインフラを共有しているので、ピークタイムが重なるとどうしてもリソースの奪い合いになってしまう状態があります。 今回、テーマにしているCPU Stealについても、グラフを持ってきています。グラフを見ると、12時過ぎから1つ目のピークがあって、15時頃、22時頃にもピークがあります。先ほどから言っているCPU Stealとはなんぞやというと、今回の例でいうと、あるHypervisorの上でVMが2台（VM1、VM2）動いている時に、それぞれのVMが10秒ずつCPUを使いたいとHypervisorに要求を出すとします。この場合、Hypervisorとしては各VMに10秒あげるというスケジューリングをしますが、リソースの状況などで必ずしもVMが10秒使えないというケースが起こります。この場合、VM1が実際には8秒しか使えなかったとすると、差分の2秒がCPU Stealとなります。 CPU Stealが起きると何が発生するかというと、ひとつはサーバー処理能力が低下します。HTTPサーバーであればレイテンシが落ちたり、データベースであってもクエリのレイテンシが落ちるとか、レイテンシが落ちていくとどんどん接続がスタックしていくので、接続数が増加して、場合によってはMax Connectionsに到達してサービスが提供できなくなるということが起こります。あとは、ロードアベレージをはじめとする各種サーバメトリクスが悪化していきます。 このような、リソースの奪い合いによって発生するCPU Stealに関する問題を解決するための手段が、我々が作った「スーパー☆ライブマイグレーション」です。 スーパー☆ライブマイグレーション 最初に、「スーパー☆ライブマイグレーション」の前提となる、ライブマイグレーションについて簡単に説明します。ライブマイグレーションとは、簡単にいうとVMを停止することなくHypervisor間を移動させるという技術です。ここでは、VM1を左から右のHypervisorへ持っていく例を紹介します。 まずライブマイグレーションを実行しようと思うと、共有ディスクがない場合ですが、まず左のHypervisorから右のHypervisorに対してVMのDiskをコピーしてあげます。続いて、Diskのコピーが終わったら、Memoryを転送します。ここでMemoryとDiskの静止点を待ってHypervisorを切り替えていくのですが、静止点を待つのにKVMとかOpenStackとかではパラメーターがあって、どのくらいダウンタイムを許容するかのパラメーターを持っています。こういったパラメーターをチューニングして、許容できるダウンタイムの中で静止点を取って、静止点が取れたら左側のHypervisorから右側のHypervisorにVMが動いて、ネットワークが切り替わって、右のHypervisorでVM1が動き始める、というのがライブマイグレーションです。 では「スーパー☆ライブマイグレーション」は何をするのかというと、ライブマイグレーションをするだけでなく、ある種スケジューリングまでをやってくれるマイグレーションを呼んでいます。 まず、VMのStealの発生を検知したい。Stealが発生してパフォーマンスが低下しているのを検知したらスケジューリングしたいという感じです。スケジューリングについては、Stealの発生していない、より空きがあるHypervisorにスケジューリングしたい。そして、ダウンタイムを発生させたくない。先ほどパラメーターをご紹介しましたが、ライブマイグレーションで静止点を取るにあたり、どのくらいダウンタイムを許容するかというパラメーターを先ほどご紹介しました。ということは、ライブマイグレーションは”ライブ”とはいいつつある程度はダウンタイムを許容するような仕組みです。それをなるべく発生させないようにしたい、あとはこれらが自動ですべていい感じに動いて欲しい。 今回我々はRubyで実装しました。VMのSteal発生検知については、Stealが発生している、かつ、Loadアベレージがしきい値以上という条件で検知するようにしています。これはなぜかというと、Stealが発生していたとしても、処理が詰まっていなければ別に問題ないので、処理が詰まっているかつStealが発生している場合にライブマイグレーションをするようにしています。 続いて、Hypervisorのスケジューリングです。これは、メトリクスのStealがしきい値以下、かつStealがなるべく少ないものを優先して選んで、かつ、同じロールのVMが移転先のHypervisorになるべくいないというのを条件にしています。なぜかというと、同じHypervisorに同じロールのVMがいっぱい乗っていて、Hypervisorが物理障害などで落ちてしまった場合、その上に乗っているVMが全部ダウンすることになるので、なるべく同じロールのVMが、いろんなHypervisorに分散されるようにスケジューリングしています。最後に同じAZのサーバーであるということも条件にしています。AZというのはAvailability Zoneの略で、Hypervisorの群のような感じで、例えば5台のHypervisorを「AZ-1」、別の5台のHypervisorを「AZ-2」といった感じで、そのサーバーグループのような感じでAvailability Zoneを組んでいくことができます。これはが例えば別のデータセンターにAZを置いたりするのが主だった使い方になります。 必ず同じAZにスケジューリングするようにしていますが、なぜかというと、図でVM1をどこかにライブマイグレーションしたいという時に、AZ-2にライブマイグレーションしてしまうと、AZ-2が障害になった時にAZ-2がまるっと落ちてしまうので、両系が落ちてしまうことで冗長がとれないことを防ぐ、なるべく同じAZの中でサーバーを動かすということをやっています。 ダウンタイムを発生させないということについては、オーケストレーターで対応しています。我々はオーケストレーターを大きく2つ使っていて、1つはKubernetes、1つはConsulです。Kubernetesについては、いわゆるkubectl drainでpodを追い出してあげて、スケジュールしないようにする。ConsulはKubernetesを使っていないVMのところでサービスディスカバリに使っていまして、Consulについても似たような機能で、consul maint -enableとか、consul maint -disableでクラスタから切り離すことで対応しています。 Kubernetesになじみのない方にご説明しますが、kubectl drainというのは何をするコマンドかというと、node-1に対してkubectl drainと打つと、node-1で動いているpod、containerを別のnode-2に動かすことができます。かつ、以降はコンテンをスケジュールをしない、podをそれ以上置かないということができます。こうすることで、node-1からpodもしくはcontainerを追い出すことができるので、この状態でライブマイグレーションをすることで、基本的にはサービスのダウンを避けることができます。 続いてconsulについては、いわゆるヘルスチェックなどを利用して、サービスをディスカバリしてグルーピングできる機能があります。この例でいくと、node-1からnode-3まであって、かつそれぞれnginx、Webサーバーを置いている状態です。この状態でnginxmあるいはHTTPのポートがリッスンできるというヘルスチェックを書いてあげると、dig web.service.consul aでAレコードを引くと、3つのAレコードが返ってきます。こういった形で、名前解決やConsul Templateなどを利用して、構成ファイルを替えたいとかという用途でconsulを使うことが多いです。 この時に、node-3に対してconsul maint -enableを打つと、node-3がメンテナンス状態になるので、この状態でDNSの問い合わせを投げると10.0.0.1と10.0.0.2だけが返ってきて、node-3である10.0.0.3は返ってこないという状態になります。こうなると、クラスタからnode-3が切り離されているので、この状態でnode-3を安全に無停止でマイグレーションできるようになります。 処理系まとめ ここまでお話しした内容を簡単にまとめると、まずStealの発生かつロードアベレージの上昇で、ライブマイグレーション開始の判定をします。その上で最適な母艦（Hypervisor）を決定して、その状態でVMをクラスタから切り離し、ライブマイグレーションをかけて、再びクラスタへ組み込む。これを一連の流れとしています。 我々が作ったプログラムはOpenStackの上で動くKubernetesで1つのpodとして動いていて、状態を観測して、期待とずれている場合に、VMを動かして、なるべく元に戻してあげるということをやっています。 本当にあった怖い話 こんな形で実装していますが、簡単に行かなかった話もあります。一例を持ってきました。 サービスの方で運用しているSREのメンバーから「『スーパー☆ライブマイグレーション』が動いているけど、レイテンシが改善しない」という話が私のところに飛び込んできました。実際に調査してみると、ネットワークトラフィックのメトリクスで、13時ぐらいから16時前ぐらいまで、明らかにネットワークトラフィックが高くなっている。何をやっているかというと、先ほどライブマイグレーションの動きを紹介した時にDiskを最初にコピーするというお話をしましたが、VMのDiskの中にはサイズが大きいものもあって、500GBとか1TBとかを普通にライブマイグレーションして転送するとトラフィックが輻輳して破滅してしまう。対策しないとフルに帯域を使ってしまうということで、同僚が対策してくれたのは、ライブマイグレーションに使うVLANを分けておいて、そのVLANに対してrate limitを入れることでトラフィックを使い過ぎないようにするという対応をしました。同僚に感謝です。 まとめ 今日お話ししたことのまとめです。 我々がやったのは、ノイジーネイバー問題を、スケジューラーを書くことで解決しました。 最初はOSSにしようかとも思いましたが、Kubernetes のdescheduleのような感じで抽象度の高い定義はできますが、オーケストレーターの切り離しのところなどが使いやすくない感じになるので、今回はオープンソースにしない形で実装しました。 我々もやってみて分かりましたが、ライブマイグレーションはピークタイムに動くようなこともあるので、いろいろなところで同時多発的に動くとネットワーク帯域を結構食ってしまうことが分かりました。ライブマイグレーションもある程度の頻度で打つ時はrate limitを検討した方がよいと思います。 当日、私は会場にいると思うので、ぜひ食事したり飲みにいったりできるかなと思っています。 お知らせ 最後にお知らせです。 我々GMOインターネットグループのテックイベントを計画しております。GMO Developers Dayということで12/6、12/7に開催します。会場は渋谷フクラスの16階と、あとはオンラインのイベントとなります。 GMOインターネットグループは、我々の会社だけでもいろいろな領域においてサービスを提供していますが、グループだと金融や仮想通貨、あとはペイメントなど非常に広い事業領域をやっています。それぞれの事業領域のスペシャリストを集めてトークイベントをしたいと思っていますので、ぜひご都合の付く方はご参加いただければと思います。 以上で私のセッションは終わりですが、我々はいま非常に採用に力を入れております。鹿児島、東京、福岡でいろいろ採用しております。せひGMOペパボで働いてみたいという方がいらっしゃいましたら、ご応募いただければ幸いです。 採用ページ：https://recruit.pepabo.com/ 本日はご清聴いただきありがとうございました。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/jaAff02Dl-o

本イベントは、世界トップクラスのサイバーセキュリティ専門家による国際会議として、10月27～28日の2日間、東京・渋谷パルコDGビル 18階 カンファレンスホール “Dragon Gate”にて開催されました。欧米の著名研究者が参加して研究成果を共有するとともに、日本の若手研究者の研究も発信する場としても知られています。GMOインターネットグループからは、GMOサイバーセキュリティ byイエラエ社がトップスポンサーとして協賛し、セッションやワークショップへの出展などで参加しました。 イベント概要 日　時：2022年10月27日（木）～ 28日（金）会　場：渋谷パルコDGビル 18階 カンファレンスホール “Dragon Gate” + オンライン配信主　催：CODE BLUE実行委員会公式HP：https://codeblue.jp/2022/ 10回目の開催となったCODE BLUE CODE BLUEとは CODE BLUEはセキュリティに関する国際会議で、2013年の第1回開催以来、今回で10回目の開催となりました。初回には米国BlackHat創設者で、DEFCONも主催するジェフ・モス氏が登壇。2020年には台湾のデジタル担当大臣オードリー・タン氏を招聘するなど、幅広い著名講師陣を招いての講演も魅力。今年の基調講演は長年BlackHatなどで活動しているセキュリティ専門家のニール・R・ワイラー氏でした。日本語と英語合わせて、2日間で40近いセッションもあり、イベントの密度は高い。 イエラエ社は、企業ブースの出展に加え、ワークショップ会場ではWebハッキング体験 for ビギナーズを開催。トークセッションでは「Web3セキュリティ解体新書」と題したプレゼンも実施しました。 盛況なワークショップ会場 登壇セッション「Web3セキュリティ解体新書」 GMOサイバーセキュリティ byイエラエ社は、1日目のトークセッションの1コマとして、同社高度解析部高度解析課の緑川志穂、名古屋謙彦、浅野泰輝の3人が「Web3セキュリティ解体新書」と題した講演を行いました。 トークセッションにおける「Web3セキュリティ解体新書」 「Web3はソフトウェアやソリューションとしてはかなり充実してきた頃合いですが、Web3に対するセキュリティの観点ではまだまだ手探り状態にあります」。緑川はそう話し、その要因として、そもそも「Web3ソリューションそのものの構造」がモデル化できないと指摘。Web3自体の定義・分解手法があやふやというのも大きな理由で、Web3のセキュリティ対策も体系化できないと言います。そうした出発点からスタートした緑川らの研究では、次の3つの研究課題に据えました。 Web3の理想。Web3とはもともと何をしたかったのか？Web3の現実。実際のWeb3ソリューションがどのようなものか。私たちの考えるWeb3セキュリティ。 1のWeb3の理想では、まずその概念の提唱時までさかのぼります。最初に言及されたのは、元NSA（米国家安全保障局）局員だったエドワード・スノーデンによるリーク事件。これは「米国が、世間が想像していた以上に監視社会であることを知らしめた」（緑川）のですが、それに対する反応として「監視されたくない」「プライバシーを守りたい」「自分の情報は自分で設定したい」といった個人主義的な考え方に落ち着いてきたと緑川は言います。そして「これを実現する方法はないだろうか？というのが最初の（Web3の）モチベーションと」と緑川。これらを踏まえたWeb3の言葉の定義として、最初に「Web 3.0」という言葉を提唱したGavin Woodを取り上げます。Woodは「Web 3.0または"ポストスノーデン"Webと呼ばれるもの」と概説。それは、プライバシーが国や組織によって脅かされないネットワーク、という定義になっています。ちなみに、こうした考え方は1988年にすでに存在し、Timothy C. Mayによる「The Crypt Anarchist Manifesto」においては「暗号無政府主義」として「暗号技術を用いて、誰からの監視もなく、なおかつ何らか特定の信頼を置く必要もない社会」が提唱され、続く1993年にEric Hughesが「A Cypherpunk's Manifesto」で「サイファーパンク」という考え方を提唱しました。サイファーパンクの系譜を受け継ぐコミュニティにおいて発生したというのがBitcoinで、緑川は「ブロックチェーン技術自体がWeb3と無関係というわけではない状態」と説明しました。前述のWoodによる「DApp（Decentralized Application）」という概念についても説明され、ポストスノーデンWeb上でソフトウェアがどのように動くべきか、どう振る舞うべきかを定めたものとのこと。重要なのが「zero-trust interaction system」で、「すべての名前は仮名によって行われなければならない」「それらは全てセキュアに実行されなければならない」「ほとんどのサービスはtrustlessでなければならない」というのがDAppの条件とされています。仮にこのDAppが存在した場合、その実行基盤にはどういう条件が必要なのか。Woodはこれを次の4カ条にまとめているそうです。 static content publicationdynamic messagetrustless transactionsintegrated user-interface 「これらが揃っている基盤こそがWeb3（Web 3.0）と呼べる」というのがWoodの考えで、ここまで説明したのが「Web3の理想」だと緑川は言います。では現在、現実にWeb3として考えられているものに何があるか。デジタル庁が開催したWeb3.0研究会第1回資料を引いて、NFT、DeFi、暗号資産取引所、NFTマーケットプレイスといった例を挙げます。「研究の元々のモチベーションは、Web3アプリケーションを一般化して、もっと普遍的にWeb3セキュリティ自体を議論したいというもの」で、上記のようなアプリケーションなどを解体して、普遍的な成分だけを取り出すというのもひとつのやり方ではあるとしつつ、定まったやり方があるわけではない、と緑川は言います。すでに様々な研究論文や分解方法が提案されており、緑川らが採用したのは、2022年8月に発表されたQin Wangらによる「Exploring Web3 From the View of Blockchain」という論文。ブロックチェーンの立場からWeb3全体を概説したサーベイ論文だとしています。論文では、Open、Trustless、Permissionless、Anonymous、High availabilityという5つの要件が挙げられていますが、Web3アプリケーションの分解モデルも提示されており、緑川らはこのモデルを採用しているとのこと。Web3アプリケーションは、Date Access、Data Computation、Data Storageという3レイヤーによるアーキテクチャ・モデルで説明可能としており、12のパターンで分解できるというのがこの論文の説明で「少々荒っぽいパターン分けでしかない」としつつ、セキュリティ側として重視したいのはデータフローとそのプライバシーで、その観点でこの分解方法は利便性が高いとしています。 Web3アプリは3レイヤーによるアーキテクチャ・モデルで説明可能、とする立場の論文 緑川は、こうしたモデリングが可能なブロックチェーン関連のアプリケーションは「基本的に（前述の）5カ条を目指していると言える」と指摘。ただ、理想的なWeb3をブロックチェーン以外で実現しているものは「他に存在しない」と話し、「結果として"現実的なWeb3"を特徴付けているのがこの5カ条」だとしています。 加えて緑川は、「Web3とはブロックチェーンであるという議論は、短期的には真であるが、長期的には必ずしも真ではない」と話し、長期的には交換可能性も検討しなければならないと指摘。 「もし今後、Web3に本気で取り組むのであれば、ブロックチェーンに依存しないデータモデリングを考える必要がある」とまとめました。 Web3セキュリティとは何か 続いて登壇した名古屋は、Web3でも従来のソフトウェアセキュリティに近い部分が存在しているとしつつ、それだけではないという部分に言及します。それが、Web3の理想、現実の双方から検討した結果、「信頼という観念が不要な契約」（Trustless）という点が共通しているという点です。 イエラエ社高度解析部高度解析課・名古屋謙彦 現実のWeb3では、ブロックチェーンとその外部との接続が必ず発生し、そのインタフェースを「ウォレット」と表現しています。Web3アプリの認証・認可では秘密鍵を使っており、ウォレットとの認証操作が、そのまま認証・認可のトリガーとなると名古屋は説明します。「しかし今、私たちがWeb3の内部と外部を接続するインタフェースとしてのセキュリティアセスメントは足りているのでしょうか？」と名古屋は問いかけます。そこで「分権性」「Web3における認証・認可」「スマートコントラクト」という3点に重点を置いた検討を行ったとします。 分権性は、英語のdecentralization（非中央集権）ということで、権利が中央に集中しているのではなく、権利、権能が複数の場所に分かれているという意味で分権性と表現しているそうです。これは、ブロックチェーンネットワークの分権性と、DAppの分権性という2つの観点があり、前者はコンセンサスアルゴリズムの分権性に依拠していると言います。例えば対象となるDAppがHybrid Storageにあたる場合、オフチェーンのストレージが存在するため、中央集権の部分もあり、「セキュリティの観点から見た場合、分権性と中央集権が混在し、権能が偏っているのは結構重要な意味を持っている」と名古屋。ブロックチェーンにおいては、権能の大きさと攻撃を受けた場合の影響範囲が近似となります。現時点では「誰が、どの権能を、どのぐらい持っているのか」という点をDAppのWeb3活用において検討することを推奨する、と名古屋は話します。 認証・認可においては、ブロックチェーンにアクセスするためのインタフェースとなるウォレットが重要になると言います。問題はオフチェーンの場合で、通常のWebサイトへのログイン、APIの利用、モバイルアプリの利用といった場合に、どのような手段で正しく認証するのが問題になると名古屋。手法としてはデジタル証明書があり、Ethereumでも使われるEIP-712と呼ばれる、署名に決まった型とデータを使って署名するという手法があります。ただ、現状では「ユーザーに確認の責任を負わせている状態にある」と指摘します。現状の通常のWeb（Web2）にはFIDO認証があり、これもフィッシング耐性のある認証手法とされていますが、これはブラウザやOSがサイトのオリジンを保証して認証することでフィッシングなどを防止しますが、ブラウザやOSを信頼する形になるため、Web3で参考にするには分権性の問題が出てくるので検討が必要になります。「オフチェーンでの確認には限界があるということを踏まえて設計する必要がある」と名古屋は強調します。 スマートコントラクト スマートコントラクトに関しては浅野が担当。EthereumとSolidityを想定して説明がされました。こうした環境では、Web3特有としてチェーン上にすべてのデータを公開する性質やアドレスに対する権限の管理といった、「スマートコントラクトのオリジナルの視点が必要になってくる」と浅野。 イエラエ社高度解析部高度解析課の浅野泰輝 そのため、Web3以外のWebで使われるようなCWEといった指標はそのまま使えない。「言うなれば、スマートコントラクト専用のCWEのようなものが必要になる」というのが浅野の説明です。 Ethereumでは、それをEIP-1470でSWCとして定義されています。専用解析ツールMythrilで、ある程度のSWCに抵触しているかどうかを判断できるそうですが、SWC自体は更新・メンテナンスが止まってしまっています。それでもSolidityのコードを書く上で陥りやすいミスなどはある程度カバーできるそうです。「スマートコントラクトに対するセキュリティの虎の巻みたいなものは存在していない」と浅野。スマートコントラクトにおけるセキュリティが発展途上ということではあるのですが、その中でも重要なトピックとして浅野氏が挙げるのは「Reentrancy」と「selfdestruct」の2点です。Reentrancyでは、JavaのConcurrentModificationExceptionという例外を例に、シングルスレッドでも「並行制御を考慮しなければならないと言っても過言ではない」（浅野）として、スマートコントラクト開発でも並行制御の視点は広く浸透していくべき、というのが浅野の考えです。スマートコントラクトではゼロトラストという性質があり、権限の管理が非常に重要になってきます。過去には、selfdestruct命令の権限が適切に設定されていなかった事例があり、自己削除できるselfdestructを実行するにあたっては権限の設定に不備がないかを慎重にチェックする必要があります。イエラエ社がスマートコントラクトの診断を実施したところ、Reentrancyに関する問題点は発見されたものの、selfdestructにもとづく問題点はまだ存在していなかったそうです。浅野は「セキュリティとしてまだ土台が固まっていないスマートコントラクト、Web3の開発においては、常にどこかで脆弱性が見つかり、安全だと思っていたものはすぐにレガシーになってしまう危険性をはらんでいる」と強調。そうした状況を放置するのではなく、selfdestructなどを使ってうまくいなして共存できるようになる、と主張します。 最後に再び登壇した緑川は、「2つの標語を提案したい」と言います。 Web3は誰でもが参加できて、誰もが権能を持つコントラクトの人生は完全に管理しろ 加えて緑川は、自動車やIoTにおけるセキュリティが同じような考え方になっていると説明。すでにこの方面ではある程度の知見がたまっているので、そのまま流用はできないまでもアーキテクチャリングやモデリングに関しては有用という判断をしているそうです。緑川は、そうした他分野との相互作用ができることを期待し、将来的な取り組みとして今後も研究を重ねていきたいと話しました。 →後編へ続きます

こんにちは。GMOインターネットグループ株式会社 セキュリティエンジニアの谷山です。私は2020年に新卒入社し、現在はセキュリティのチームにてWebアプリケーション脆弱性診断に従事しています。脆弱性診断を行うために様々な脆弱性の知識が必要なので日々勉強しているところです。さて、脆弱性には開発者の対策漏れで発生するものだけでなくそもそもプログラム言語に用意されている処理で発生してしまうものがあります。今回は、PHPなどの関数で用意されているシリアライズに潜む脆弱性についてPort Swiggerが公開しているWebSecurity Academyのページを使って一緒に挙動を見ていきましょう。 注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。 自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 シリアライズされたデータ まず、シリアライズとはアプリケーション上の構造を持ったデータを保存・伝達する目的でバイト列に変換する事をいい、反対にシリアライズされたデータをもとに戻ることをデシリアライズと言います。 ん・・・・・？ なんだかよく分かりませんよね？私も言葉を聞いても良く分かりませんでした。今回のテーマは「手を動かして理解する」ですので実際にテストページを見ていきましょう。 こちらがテストページのログインリクエストとレスポンスになります。 特にレスポンスに注目するとSet-cookieされているsessionの値は下記になっていますね。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjowO30%3d 一度ログアウトして再度ログインした際のSet-cookieされているsessionの値は上記に記載したものと全く同じでした。 つまり、乱数でsessionの値を生成しているのではなくユーザーごとにある規則性で生成されていそうですね。 先ほどのsessionの値を詳しくみていきましょう。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjowO30%3d 値の最後に%3dとありますのでURLエンコードされていそうです。URLデコードしてみましょう。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjowO30= %3dはURLエンコードで=になりましたね。この=で、何か引っかかる方もいらっしゃいますかね？この=というのは、とあるエンコード方式の特徴になっています。そのエンコード方式というのは「BASE64」と呼ばれるものです。BASE64でエンコードした場合は最後に4文字区切りで足りない文字は=で補います。 本記事ではエンコード・デコードの解説はしませんが、気になる方は別途調べてみてください。 少々エンコードの話をしてしまいましたので話を戻しましょう。テストページのログインレスポンスのSessionの値をURLデコードしたら最後に=がありました。これはBASE64でエンコードされている気がするのでさらにBASE64でデコードしてみましょう。すると下記文字列になりました。 O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:0;} どうでしょうか？何となく読める気がしませんか？実はこれがシリアライズされたバイト列になります。シリアライズ形式はデータの先頭に型やサイズがありその後データの文字列が続いています。こちらを見ると下記のデータがありそうです。 username：wiener、admin：0 以上が実際のサイトで使用されているシリアライズされたバイト列の例になります。 権限昇格を試みる 先ほど、シリアライズされたバイト列を確認しましたね。もう一度確認していきましょう。 O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin"; b:0;} 特に最後のadminのところが気になりますよね。b:0とあるのでBoolean型の0だと考えられますね。という事はb:1に変更するとどうなるのかやっていきます。 テストページでログインすると下記のような画面になっています。 この時のリクエストとレスポンスは下記のとおりです。 リクエストにはやはり先ほどと同じ値のcookieを持っていますね。こちらに改ざんしたcookieを差し込んでいきます。 まずは先ほどBASE64デコードしたsessionの値のb:0部分をb:1に変更します。 O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin"; b:1;} 変更したらこの値をBASE64でエンコードします。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjoxO30= この値をさらにURLエンコードした文字列をMy-accountページを表示する際のcookieの値に指定すると 画面は下記になりました。 こちらをよく見てみるとAdmin panelが表示されていますね。AdminのBoolean型の値を1にしたことでAdmin権限として表示されたことになり実際に権限昇格が実行出来ました。 おわりに いかがでしたでしょうか。このようにプログラム言語に関数として機能がありますが、使い方を考えないと思いもよらない攻撃をされてしまう可能性があります。基本的にはシリアライズ機能は使わずにJSON形式などでデータを受け渡しする方が良いとされています。昨今のサイトではほとんど使用していない気がしますが、昔に作成したサイトをそのまま運用しているというような場合はシリアライズ機能がないかチェックしてみると良いかと思います。

　Microsoft365のPower Automateを使って、自動的にMicrosoft Teamsのチーム作成やチャネル作成が可能となります。この中でチームの作成については、パブリックチーム、プライベートチームともにPower Automateから作成可能ですし、パブリックチームを手動にてプライベートチームに変更することもできます。一方、チャネルについては、パブリックチャネルのみ作成可能で、後から手動での変更もできません。そこで、今回は、Microsoft Graph を組み合わせて、Power Automateからプライベートチャネルを作成する方法を紹介します。 Microsoft Graph とは 　Microsoftの様々なクラウドサービスは、Webの管理画面やPower Automateなどから利用できる以外にも、数多くの機能が提供されています。それらをプログラムなどから利用するためのインターフェース群（API）がMicrosoft Graph API となります。（Microsoft Graph の概要 - Microsoft Graph | Microsoft Learn）HTTPのリクエストやPowerShellから呼び出すことができるので、今回のようにPower Automateの標準では提供されていない機能もMicrosoft Graph APIみ合わせることで機能拡張が可能となります。 Azure Active Directory でアプリの登録 　Microsoft Graph を利用するにはAzure Active Directoryにアプリの登録を行い、アプリに権限を割り当てる必要があります。割り当てる権限によって、チャネルの作成や、ユーザーの追加など様々なAPIの機能が利用可能となります。Microsoft365の管理センターからAzure Active Directory管理センターを選択します。「Azure Active Directory」-「アプリの登録」-「新規作成」を選択します。 アプリケーションの名前を設定して、以下このような内容で登録します。 登録されたアプリケーションの「概要」を選択します。ここでは「アプリケーション（クライアント）ID」と「ディレクトリ（テナント）ID」が後程必要となるのでメモしておきます。 次に証明書の発行を行います。「証明書とシークレット」を選択して、「新しいクライアントシークレット」を選択します。説明を入力して有効期限を選択して「追加」を選択します。 「値」の部分が後程必要になるのでメモしておきます。 次に「APIアクセス許可」を選択して「アクセス許可の追加」を選択します。 一番上にある「Microsoft Graph」を選択します。 「アプリケーションの許可」を選択します。 アクセス許可を実施するリスト一覧が表示されます。この中からプライベートチャネルを作成する際に必要なアクセス権を選択してゆきます。必要なアクセス権はこちらのページ（チャネルを作成する - Microsoft Graph v1.0 | Microsoft Learn）から「アクセス許可」-「アプリケーション」の項目を参考にします。 このような要領で全ての必要な項目を選択して最後に「アクセス許可の追加」を選択します。※Channel.Create.Groupはリストに無いので選択不要 アラートがいくつか出ていますが、管理者の同意が必要ということなので、最後に「管理者の同意を与えます」を選択してアプリの登録は完了です。 Power Automateでフローの作成 　次に、Power Automateから登録したアプリ（Microsoft Graph）を呼び出すためのフローを作成してゆきます。インスタンスフローを新規で作成します。アプリの呼び出し方は、HTTPリクエストを送信することになります。通常HTTPリクエストの送信にはプレミアムコネクタが必要となりますが、呼び出すMicrosoft Graphの機能によってはプレミアムコネクタを必要とせずにMicrosoft365のコネクタを利用することで代用可能な場合もあります。今回は2通りの呼び出し方を紹介します。 HTTPコネクタ（プレミアム） まずはプレミアムコネクタの「HTTP」を利用した方法です。アクションから「HTTP」を選択します。 ここで必要となる情報として、先ほどアプリ登録の際にメモした“アプリケーション（クライアント）ID”、“ディレクトリ (テナント) ID”、“シークレットの値”と、プライベートチャネルを作成するチームの“チームID”となります。チームIDの調べ方は色々あります。今回はTeamsからチームのリンクの取得を選択してリンクから取得します。取得したリンクを見てみると“groupid=〇〇〇”とあるので、〇〇〇の部分（青字）がチームIDとなるのでメモしておきます。 https://teams.microsoft.com/l/channel/19%3at-bAv34L1KjjZG9lIs41JzKcvGfxViQ5C-oJIhpCsUU1%40thread.tacv2/%25E4%25B8%2580%25E8%2588%25AC?groupId=c96ffd4c-a96d-4452-a7af-7bf4b3a1612e&tenantId=edaa4d8b-ddfd-427c-9ab3-e6d841348b94 フロー作成画面に戻ります。「方法」は“POST”を選択します。URIは https://graph.microsoft.com/v1.0/teams/「グループID」/channels のような形式でグループIDを指定します。本文のjsonは以下となります。ユーザーアカウントの部分には、プライベートチャネルの所有者となるアカウントを指定します。 { 　"@@odata.type": "#Microsoft.Graph.channel", "displayName": "<チャネル名>", "membershipType": "private", "members": [ { "[email protected]": "https://graph.microsoft.com/v1.0/users('<ユーザーアカウント>')", "roles": [ "owner" ] } ] } 続いて、「詳細オプションを表示する」を選択します。テナント：“ディレクトリ (テナント) ID”クライアントID:：“アプリケーション (クライアント) ID”シークレット：“シークレットの値”の値をそれぞれ入力します。 その他は同様の内容となります。 こちらで完成です。テスト実行してみましょう。 プライベートチャネルが作成されました！ Office365コネクタ（Users/Groups） 　次にOffice365コネクタを利用した方法です。Office365コネクタの場合、「Office365 Users」、「Office365 Outlook」、「Office365 Groups」など数種類ありますが、どれにも「HTTP要求を送信する」という名前のアクションがあり入力項目も同じとなりますので、同様に利用可能です。今回は「Office365 Groups」コネクタを利用します。 Office365関連のコネクタを利用する場合は、コネクタのログイン情報を利用してリクエストを送信するので、Azure　Active Directoryに登録したアプリ情報は不要となります。従ってとてもシンプルな設定項目となっています。 上記で作成したフローを実行すると、同様にプライベートチャネルが作成できました。 　以上、Power AutomateからMicrosoft Graphを利用したプライベートチャネルの作成方法となります。コネクタによる呼び出し方の違いとしては、「HTTPコネクタ（プレミアム）」の場合は、コネクタのアカウント情報は不要でAzure Active Directoryに登録したアプリの権限によって実行されます。「Office365 HTTP要求の送信」の場合は、利用するコネクタのログインアカウントに基づいた権限で実行されるという点にあります。後者の場合、実行するユーザーがMicrosoft365のグローバル管理者であれば実行権限について問題ありませんが、一般ユーザーのアカウントの場合は呼び出すMicrosoft Graph APIによっては権限が足りずに実行できない場合もあります。そのような場合は、Azure Active Directoryに登録したアプリに適切な権限が割り当てられていれば、問題なくMicrosoft Graph APIを呼び出すことが可能となります。さらに、登録されたアプリは外部からプログラム経由で呼び出すことも可能となります。利用するユーザーやシーンによって、登録アプリ経由か、コネクタの実行アカウントで実行などうまく使い分けるとで、効率よくMicrosoft Graph APIが利用できるようになります。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5Gについて簡単にご説明させていただきます 簡単に 簡単にローカル5Gとは何かというとこれまで携帯キャリアが行っていた 「特定の周波数の電波を使い排他的に無線通信を行う」 ということを一般事業者も参入できるようになったものです ざっくり言うとマイ5G（マイホーム的な）だと思ってもらって大丈夫です どんなメリットがあるのか？ ローカル5G環境を構築するためには国へ申請を出す必要がありますそうやって国から免許をもらうことで電波のうち一定の範囲の周波数を排他的に利用できます 排他的に利用できるということは既存のWi-Fi等で起こる電波干渉がなくなり、他者の通信に起因する悪影響がなくなるので安定した通信が可能となるということが大きなメリットです もちろん携帯キャリアの5Gと同様の技術を使うため大容量、他接続、低遅延といった5G自体のメリットも享受できます 携帯キャリアの5G、ローカル5G、Wi-Fiの違いは？ 携帯キャリアの5Gはキャリアさんが設備を全て用意/管理してくれ特定多数のユーザーがそれをシェアする形のため程々の費用で快適さは他のユーザー次第の通信になります ローカル5Gは自分で設備を用意するため費用はかかるもののユーザーは免許を受けた電波を独占することができ安定した快適さが保証された通信となります Wi-Fiは個々人が思い思いに設備を用意するため近隣のWi-Fi設備の影響を受け、さらには無線キーボードやマウスといった同じ周波数帯の電波を利用する機器からも影響を受けることがあり設備自体の費用はかなり抑えめですが、通信の快適さは周囲の環境次第という博打的なものとなっています 住居にたとえるならば 「携帯キャリアの5G」は管理会社が面倒を見てくれる「寮」「ローカル5G」は自分で住環境を整え、管理しなければならない「分譲マンション」「Wi-Fi」は快適なときは快適だが酷いときは酷い「キャンプ」 といったところでしょうか ですので正直なところ、このうちのどれを選ぶかはコストと求める品質で要相談だと思います まとめ まとめると ローカル5Gとは自分・自社用のマイ5Gであり多少のコストはかかるが高品質で安定した通信が必要な方向けのもの となります 以上、簡単ではありますがローカル5Gとは？でしたお読みいただきありがとうございました 関連記事 https://developers.gmo.jp/23934/ https://developers.gmo.jp/3938/

9/21（水）にGMO Developers Night#36 「 経済産業省×GMOサイバーセキュリティbyイエラエ「開発段階におけるIoT機器の脆弱性検証促進事業」について 」をオンラインにて開催。IoTにおけるセキュリティ対策の必要性や有無、また、経済産業省が行う取り組みについて、お話いたしました。 ▻イベント告知：https://developers.gmo.jp/20150/今回Vol.03では、 座談会・Q&Aコンテンツ の書き起こしをお届けします。 Q.WebとIoTの脆弱性で大きな違いがあれば教えてください 今回のセミナーに申し込む時に使用している申し込みサイトがWebですが、IoTは装置。脆弱性の大きな違いは、Webの方であれば大きなパソコンを使って、サーバーなどでいろいろやっていますが、それらに実際に診断を行った時にサーバーの上で何か動かす、例えばマイニングであったりとか変なものを動かされたりとか、そういったものがあります。IoTですと、Webと似たようなところで個人情報などが装置から抜かれてしまう可能性があるというのもありますが、もう1つ、IoTはサイズが小さい。小さい機器で動かさなくてはいけないというところで、脆弱性の対策とかセキュリティ対策をたくさんやると、イメージとしてはパソコンにウイルス対策製品を入れると重くなりますが、同じような感じでただでさえパワーが弱いIoT機器にそんな製品を入れられない。でも対策しなければいけない、ということで、結構大きめの穴が開いたままで動いているIoT機器があるとか、あとは皆さんがいろいろカスタマイズしているので、既知の脆弱性ではないけれども、ちょっとコードを読むことですでにいろいろと攻撃されている脆弱性の変化球があるということも分かります。まとめると、そこまで大きな違いはないが、それぞれの事情から細かいところを見ると脆弱性の違いはあります。IoTは特有の脆弱性があり、Webは特有の脆弱性があり、Webの方はよく調べられているけど、IoTの方はあまり調べられていないからまずい、というところはあります。三村 Q.IoT利用者目線で、簡単にできるセキュリティ対策があれば教えてくだ 一番最初に、パスワードをちゃんと変更してくださいというものがあります。また、最近だとRaspberry Piのような小さい装置がありますが、OSがデフォルトのままで入れた状態だと、何の対策もされていないOSに、パスワードがデフォルトの状態でやられ放題になってしまう。そういう機器であれば、ファイアウォールを設定しましょう、パスワードを変更しましょう、といったことになります。また、アップデートがあればしていきましょうというところが重要なところになってくると思います。ほかの機器でもアップデートが出ていれば実施するし、ベンダーさんからこの機器はもうサポートしませんと言われているのであれば機器を交換する。パソコンに近い形の対策が利用者目線だと一番重要でかつ簡単にできる対策だと思います。三村 Q.IoTの持つセンサーへの攻撃などは評価していないのでしょうか？ もちろん、センサーへの診断は行っています。センサーへの攻撃はどういうふうに評価を解釈するかになりますが、脆弱性に何か攻撃される穴があったり攻撃されたりということがあるかといえば、当然YESです。分かりやすい例ですと、池があったとしましょう。そこに水温を測るセンサーがあったとして、これがIoT機器です。水温が高ければ水を入れて温度を下げる、低ければヒーターを動かすといった"IoTの池"があったとすると、攻撃は水温センサーの値を変な値で返してあげる、サーバーとクライアント（センサー）との通信をいじって、その池は本来ならば二十何℃が正常なのに5℃です、という情報をサーバーにあげる。するとヒーターが動いて池の水温が上がって、池の鯉が死んでしまうかもしれない。こういった攻撃は当然ありますので、その対策や、脆弱性診断は当然重要ですし、我々としてもそういうところの診断依頼は当然来ておりますしやっております。三村 Q.各種脆弱性診断を定期的に行うタイミングなど、指標があれば教えてください。 まず、セキュリティ・バイ・デザインのところから考えると、まずソースコードや、その前の設計段階、基本設計のところだと、例えば通信を暗号化すると、その暗号の方式はちゃんと安全なものですか？と。一例を挙げますとDESとかSSLの暗号でも例えば128ビットとかは最近は使っている例はないですけど、そういうものを仕様書で使いましょうと書いてあれば、そのタイミングで相談いただければ、これは確実に危ないです、これを使っていたら危険ですというものはできますし、基礎のタイミングのところから安全にしていくことはもちろんできると思います。もちろん、設計がしっかりしていて、開発もしっかりしていたとしても、その後のところで診断をした時にここのタイミングで何が見つかるかという話になりますと、例えば設計して実際にシステムを作りました、そこのところで例えば仕様書に書いていないような設定がありましたと、SSHやVPNをしゃべるようなソフトを入れますと、これのデフォルト設定については仕様が特にありませんでした、なのでそのままにしています、という時にここのところで発見というのはあるでしょうし、また実際に組み上がった時にチップやボードで何かこちらから指示はしていない、向こうの方で同じようにここのところは特にケアしなくて渡してしまえばよいといった形で、誰もケアしなかった脆弱性の穴があるということになれば、最後のところで当然発見という形になります。なので、診断は両方とも当然やった方がいいですし、可能であれば当然早いタイミングで行うことができれば、後段で見つかるものは小さいものになりますし、手戻りが少なくなるので当然スムーズにすべてが進むようになるので、早いタイミングからの相談をもし可能であればお願いしております。三村 伊藤各社のつまずくところは、実は各社毎では個別のノウハウですが、我々診断会社はみんなから吸収しているので、共有値というか、ナレッジのデータベースみたいなものだと思うので、開発に着手する時にも、我々みたいな診断会社を特に失敗のナレッジデータベースの感じで使っていただくと、同じような失敗をせずに物事がうまく進むと思っていますので、こういったところをうまく使っていただければと思います。 Q.サービスの穴をついてくることと防ぐことはいたちごっこのような気がしているのですが、継続的に対策できるサービスはお考えですか？ サービスの穴、一般的には守るのは全体を守らなければいけないけれど、攻撃はそのうち1個でも突破できればよいということで、いたちごっこという話はよく出ています。継続的に対策できるというところで1つあるのは、ソフトウェアのアップデートをしっかり管理したうえで行える状態にするということ。また、製造ベンダー側であれば新機能が追加される時にはちゃんとその機能がどういうものかをしっかり管理をしていく。作って終了ではなくて、どんどんアップデートとか、外から脆弱性の話があった時にちゃんと対応できる体制を作っていくというものが、まず基礎として大事になってくると思っております。もちろんその回し方に関するところは、やはり各社のやり方に絡んでくると思いますので、そこは伊藤さんにサービスという形で少し絡めて説明いただければと思います。三村 伊藤基本的には、やはり外部の攻撃はインターネットに繋がった外側のところだと思います。外側のところを我々のホワイトハッカーの考え方でアタックサーフェスといいますが、どこから侵入するのかというところを常に見ていくわけです。これで自分の知らないアタックサーフェスとかインターネット経由の入口があると、そこが盲点になってしまいます。逆にアタックサーフェスなので、こんな入口しか空いてないのにここを重厚長大に騒ぐのは費用対効果が悪かったりするので、こういった観点でアタックサーフェスをドメインとかIPアドレスからあぶり出して管理できるようなサービスとか、ホワイトハッカー視点でここが侵入口でここが重要なところですよ、入口が開いているといっても人間が通れる穴なのかネズミしか通れないのか、希釈化するとみんな入口が開いていますと言われてしまうので、こういったところのプライオリティ付けが自動でスキャンできるサービスを今GMOサイバーセキュリティ byイエラエの中でも検討していて、それをヘルスチェックの形でお出してきるような取組も進んでいる状況でありますので、ぜひご期待をいただければと思っています。 ご視聴・ご参加いただいた皆様、誠にありがとうございました。映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=SDT0zu9_T8U 連載記事はこちら https://developers.gmo.jp/25025/ https://developers.gmo.jp/25547/

9/21（水）にGMO Developers Night#36 「 経済産業省×GMOサイバーセキュリティbyイエラエ「開発段階におけるIoT機器の脆弱性検証促進事業」について 」をオンラインにて開催。IoTにおけるセキュリティ対策の必要性や有無、また、経済産業省が行う取り組みについて、お話いたしました。 ▻イベント告知：https://developers.gmo.jp/20150/今回Vol.02では、 【セッション②】開発段階におけるIoT機器の脆弱性検証促進事業について の書き起こしをお届けします。 【セッション②】開発段階におけるIoT機器の脆弱性検証促進事業について 登壇者経済産業省商務情報政策局 サイバーセキュリティ課長奥田修司 氏 私からは、開発段階におけるIoT機器の脆弱性検証促進事業を進めておりますので、どうして経済産業省がそのような事業を進めているのかというところも含めてご紹介します。 資料は、それらも含めていろいろなものを今日持ってきていますので、途中飛ばしてしまうところもあるかもしれませんが、あとで資料は皆様にお届けできると聞いておりますので、お時間がある時にでも見ていただければと思います。 最近の攻撃動向と産業界へのメッセージ いきなり飛ばしてしまいますが、最近のサイバー攻撃の状況などについては、あとで見ていただければと思います。 最近のサイバー攻撃の状況に関して経産省よりぜひ皆さんに考えていただきたいことを、ある意味当たり前のことをまとめたような文章になっておりまして、きちんとやっている人はやっているよっていうことですが、そうではない人たちがサイバー攻撃に遭う状況にありますので、そのような方々ににぜひこのようなものが経産省から出ているよとご紹介いただければよいかなと思って、こういうものを出しています。 経済産業省のサイバーセキュリティ対策 経産省の政策はいろいろありますが、今日ご紹介するのは資料の青い枠で囲っているものでして、いろいろな分野別カテゴリでガイドラインやフレームワークを作成して、民間のいろいろな事業者の方々がサイバーセキュリティ対策に取り組もうと思った時に参考にしていただけるものを、様々な有識者の人たちのご意見をお聞きしながら作っているものになりますので、ぜひいろいろなものを作っているのを見ていただければということですが、その一部を今日ご紹介させていただければと思います。 IoT機器に対するセキュリティ対策の必要性 今日お話をさせていただければと思っていたIoT機器についてですが、セキュリティ対策の必要性ということで、先ほども三村さんの方からもいくつかの事例をもってお話をしていただきましたが、実際にセキュリティの事故でIoT機器やOTシステムが止まってしまったという経験のある人がだいたい25％、1/4ほどいるということもありまして、サイバーフィジカルの繋がり、サイバー空間とフィジカル空間との繋がりが増えてきている中でIoT機器やOTシステムへのサイバー攻撃などによる停止が増えてきているのだと思っています。 実際にはそういった攻撃を受けてしまうと、例えばリコールを求められることになったりとか、その製品のメーカーに対する訴訟が起こされたりとかということで、実際に自動車の例であれば140万台のリコールが求められたりとか、心臓のペースメーカーで46万台のリコールに繋がったりとかと、やはりどうしてもこういった脆弱性を残して製品を出荷して影響が出てしまうと開発企業にも影響が出てしまうので、どれだけ事前に対策をしていけるのかをぜひ考えていきたいということでございます。 セキュリティとセーフティの融合への対応 ～IoTセキュリティ・セーフティ・フレームワーク（IoT-SSF）の策定 そのために大事になってくるのはどういうことかということでまとめたのが、「IoTセキュリティ・セーフティ・フレームワーク（IoT-SSF）」と言っておりますが、サイバー空間とフィジカル空間の間をつなぐ第2層、まさにここでIoT機器が活躍をしているわけですが、ここでしっかりと情報の伝達ができるかどうかとか、誤った命令が送られていないかとか、また誤った動作をするようなことにならないかも、しっかりと担保するようなIoT製品を作っていかないといけないということになります。 IoT-SSFの枠組み／ユースケース集の作成 枠組みとしては、どういったことを考えて開発を進めていけばいいのかということを具体的なユースケースを元に分かりやすく解説をしようということで、ここに挙げている6個、ドローンもその中の1つに入っていますけども、6つのケースでリスクアセスメントをどのようにすればいいのかということと、リスク対応をどういうふうに考えていけばいいのかということをまとめたものを公表していますので、ぜひお時間あれば見ていただければと。 このユースケースの中に入ってないといけないのかというとそうではなくて、自分たちが開発をしているものや使っているものを見た時に、自分たちのものだったらこういう風にこのフレームワークを当てはめていけばよいということで見ていただければと思いますので、比較的近いものを参考に見ていただきながら自分たちの製品とか、使っているものに当てはめていただくことが重要と思います。 IoT-SSFに基づくリスクマネジメントのプロセス 実際にリスクアセスメントやリスク対応に向けてどういう事前準備をすればいいのかということと、リスクアセスメントをどうすればいいのかということをまとめていますが、特にこのフレームワークの中ではリスクアセスメントのところは2軸でリスクを分析したらどうかということで提案しています。 第1軸は回復困難性の度合いで、例えば死亡事故に繋がるようなリスクは回復困難とみなさざるを得ないと思いますし、そういった回復困難性がどこまで大きいのかということ。 第2軸は経済的影響の度合いで、幅広く世の中に活用されているものについては影響を受ける人々が多くて、経済的な影響度合いも大きい。 この2つの軸でリスクをきちんと分析をして対策に照らし合わせていこうということです。 サイバーセキュリティ対策の中で重要なのはやはりこのリスクアセスメントで、リスクに応じた対策をとるということを考えていかないと、対策コストがどんどん積み重なっていってしまって、実際にそぐわない、高価な製品しかできなくなってしまいますので、そこはきちんとアセスメントをするということです。 そのうえでリスク対応を考えていこうということですが、このリスク対応のところでこのフレームワークの中でポイントとして挙げているのは、4つの観点で整理をしようと考えております。 第1の観点は製品開発段階、実際に運用前の設計とか製造段階でその機器システムに要求する事項はどういうものなのかということ、第2の観点として運用中に機器システムに要求するものは何かということ、第3の観点としては、運用中のシステムの運用や管理を行う者の能力に関してどういう要求をしていけばいいのかということ、それから第4の観点は社会的なサポート、例えば保険みたいなものをどう考えていけばいいのか、こういった4つの観点をうまく組み合わせることによってコストを抑えながら必要な対策をとれるということをまとめたものになっておりますので、ぜひご覧いただきながら考えていただければというものになっています。 今日は飛ばしてしまいますが、実際にリスク対応の検討やその時の参考になるようなリスト類がまとまった資料になっております。 最後に、今日のテーマでもあるIoT機器の脆弱性の検証促進ということについてお話をさせていただければと思います。 包括的なサイバーセキュリティ検証基盤を構築し、『Proven in Japan』を促進 経済産業省で『Proven in Japan』と言っていますが、いろいろなものをしっかりと検証しながら有効なものをしっかりと活用していこうということで、例えばセキュリティ製品の検証をどうしていくのかということや、まさに今日の話に繋がる、攻撃型を含めたハイレベルな検証サービスを日本の中でしっかりと育てながら活用して、よりセキュアな社会を作っていきたいということを取組んできたわけですが、このハイレベルな検証サービスを、例えばIoT機器で展開をしていこうとすると、製品化されてしまった後に検証して脆弱性がたくさんあるから何とかしなければと気付いても遅いので、開発段階からセキュリティ・バイ・デザインという形で開発をしていくための取組に力を入れて進めていきたいということでこの事業に繋がってきています。 中小企業に対するご協力依頼事項 先ほど三村さんからもご紹介をいただきましたが、中小企業の皆様にご協力をお願いしまして、中小企業が開発をしているIoT機器やその部品についてご提供をいただきながら実際に検証をやってみるということで、三村さんからご紹介をいただいたいろいろな脆弱性の検証を、提供いただいた機器にやってみることを事業としてやりたいと思っています。 なぜこういうことをやるのかというと、アンケート調査でいうと実際に今製造段階で6割程度がまだセキュリティ対策を行っていないとか、出荷前の検証も4割程度の方がまだ実施をしていないという結果が出ています。実際に開発の途中でどういったことを検討されながら開発されているのかといった実態をまずしっかりと把握したうえで、今その中小企業の方々がIoT機器を開発していく、特に自動車、ドローン、医療機器とか、影響の大きい開発をしている時にはしっかりと検証しながらということになるので、中小企業の方々がどのタイミングでどういった検証をやっていけばいいのかというガイドラインを最終的には作りたいと思っていまして、それの材料として様々な中小企業の実態をしっかりと把握させていただきたいということで、こういった事業を展開しています。 ここでいただいた情報を実際に脆弱性検証させていただいて、それを解決していくためにどういったものにしていくのかということで、個別の製品の情報は当然外に出さないということですけども、数多く実施をさせていただいてまとめていきたいということです。 ご協力いただいた企業に対するメリット 一方で、ご提供いただいた企業の皆様にとっては、先ほども少しお話がありましたが、ある意味お金のかかる脆弱性の検証を事業の中で先ほどのような目的で実施させていただきますので、無償で脆弱性の診断を受けていただくという形になるわけです。 その中で多分出てくるのは、例えば設計書や仕様書を検証させていただく中で、開発の初期段階で脆弱性に繋がるような懸念事項が検出されるということで対策をしていくポイントが明らかになってくるとか、実際にファームウェアのバイナリ解析で脆弱性が検出されるということがあるとそこを解決していくということがその段階で分かることになりますし、また実機やプロトタイプだと機器全体の脆弱性診断から弱いところをしっかりと見つけ出して出荷前に対策をとるということになっていくわけです。 こういったことをメリットとしてとらえていただいて、ぜひご協力いただければと思っております。 申し込み要項 お申し込みの要領は、資料のQRコードから読み取っていただければと思います。 全部で百数十の機器について実証しようと思っておりまして、すでに百を超える機器が集まっていて、今月いっぱいで最終的な機器の選定を終えようと思っていますので、最終段階の駆け込みですが、ぜひ関心のある方はご応募いただいて、我々の取組にご協力いただければと思います。 まとめ IoT機器は非常に重要なポイントになってきておりますので、その中でどのような形で対策をとっていけばよいのかを我々も一緒になって考えながら皆様にどういう形で取り組んでいただければよいのかについて明らかにしていきたいということで取組みますので、産業界の皆様と一緒になってセキュリティ対策を講じていきたいと思います。引き続きよろしくお願いいたします。 開催レポートはVol.03に続きます！ 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=SDT0zu9_T8U 連載記事はこちら https://developers.gmo.jp/25025/ https://developers.gmo.jp/25604/

9/21（水）にGMO Developers Night#36 「 経済産業省×GMOサイバーセキュリティbyイエラエ「開発段階におけるIoT機器の脆弱性検証促進事業」について 」をオンラインにて開催。IoTにおけるセキュリティ対策の必要性や有無、また、経済産業省が行う取り組みについて、お話いたしました。イベント告知：https://developers.gmo.jp/20150/今回Vol.01では、 【セッション①】IoTにおけるセキュリティ対策の必要性について の書き起こしをお届けします。 【セッション①】IoTにおけるセキュリティ対策の必要性について 登壇者GMOサイバーセキュリティ byイエラエ株式会社 高度解析課課長三村 聡志 GMOサイバーセキュリティ byイエラエ 高度解析部高度解析課課長をしております三村と申します。 私からはまず、「IoTにおけるセキュリティ対策の必要性について」ということで、実際にIoT機器の診断など、どういうものを実際やっているのか、またIoT機器でどのような脆弱性、どのような攻撃があるのだろうか、こういった点を説明します。 GMOサイバーセキュリティ byイエラエとは 最初に、我々「GMOサイバーセキュリティ byイエラエ」は、「誰もが犠牲にならない社会を創る」ということをテーマに、かなり多くのハッカー、もちろん攻撃をする人たちではなく、攻撃をする人たちと同じような思考や技術を持った人たちを多数揃えまして、攻撃者よりも早く、攻撃者と同じような、もしくはそれよりも高度な技術で、何か脆弱性はないだろうか、悪用されることはないだろうかということを診断という形で提供させていただいている集団です。 また、「最強攻撃　最高品質　最低価格」を掲げております。どんな高度な診断をするといっても、皆様のところには届かないような高い値段で出しますと、別の意味で世の中を良くするというところから反しますので、技術をちゃんと提供させていただきながら皆様へはご利用いただきやすい値段で提供しております。 弊社の簡単な数字の説明になりますが、トップクラスのホワイトハッカー数、120名が在籍しております。また、6000件超とありますが、Webや最近では企業に対してペネトレーションテスト、攻撃者のふりをして侵入し、脆弱性の問題がないかを調べる形の診断から、今回のテーマであるIoT機器や組み込み機器に対する診断まで、幅広く対応しております。 ご覧になっている方の中では、「イエラエセキュリティ」という名前であれば知っているという方もいらっしゃるかもしれません。今年2022年、GMOインターネットグループにジョインいたしまして、社名を「GMOサイバーセキュリティ byイエラエ」に変更しております。よく、グループにジョインして何か変わったのですか？と聞かれることがありますが、技術力等々は前からも変わらず、また前以上に腕を磨いておりますので、安心してご依頼いただければと思っております。 IoT普及に伴いセキュリティリスクも増加 では、本題であるIoTは今のところどうなんだというところをお話しいたします。 IoTといっても、様々なものを想像されると思います。例えば、私はプレゼンテーションを進めるためのコントローラーを持っていますが、これがもしインターネットに繋がっていて、YouTubeなどいろいろなメディアで見ている皆さんの側から、このコントローラーにもし侵入できたら、どんなことがあるでしょうか？これを考えてみると、例えば、私が今これからお話しするスライドを、私が話し切る前に前に進めたり後ろに進めたりといったことができるようになってしまいます。そういうことをされると私が困るわけですが、こういうことをしないように・されないように、安全に我々のところで一度チェックをさせていただいて、穴がないだろうか、あれば一緒に直していきましょうという活動になります。 資料では、「IoT普及に伴いセキュリティリスクも増加」と書かさせていただいております。 まず、デバイスのインターネット接続が当たり前になっています。 例えば私も自宅でインターネットに繋がる調理釜を購入しましたが、数年前だと調理釜がインターネットに繋がるなんてことはなかったはずです。最近だと、こういうものがインターネットに繋がることによって、外からメニューや料理の作り方を入手してより高機能、より様々な料理ができるような機能を持ったものが出てきています。こういうものは、サイバー空間とフィジカル空間の融合、そしてそれに伴うセキュリティ上のリスクが当然出てまいります。先ほど例に挙げたプレゼンテーションを進めるための装置でもそうですし、先ほどの電気釜一つとったとしても、意図しない料理を作られたらやはり困ります。 このような世の中に対して、まず喫緊で議論が行われている代表例として2つ、自動車とドローンを挙げて説明します。 最初の例が自動車です。今、各社自動走行を目指していろいろと進められていますが、自動車は高度化がどんどん進んでおります。アクセルを踏んだだけでも、それをそのままエンジンに伝えるわけではなく、ちゃんと燃料などを考えて一番エコな状態でエンジンを動かす、そのためには裏側でちゃんとチェックをして一番良い燃料の出し方を計算するチップ、計算機というものが載っています。 同じような形でカーナビゲーションでも、自動車を運転しているとカーナビに渋滞情報がリアルタイムで出てきますが、これは中に計算するチップが載っていて、それが外と通信をしているというところからできるようになってきています。自動車ですと早いタイミングでこういうふうに高度化・電子化が進んでいて、今は自動走行ということでやっていますが、こちらに際してはこういう対策をしなければいけないとか、こういうことを確認しましょうとかを要件仕様書の形で比較的早いタイミングで作られています。 日本ですとJASPARさんとかが出していますが、こちらの基準に従っていなくても、ベースラインのところは誰が作っても作った時にまずここのレベルで安全なところは守りましょう、できるようにしましょうとか、いろいろな会社さんと手を組みながら一緒になって進めている現状があります。 一方でドローンは、最近ですと様々なところで利用されているのをニュース等でもお感じと思いますが、グラフにもあるようにドローンの利活用はどんどん進んでいます。一昔前だと、おもちゃみたいなものでブーンと飛ばすというものがあったわけですが、最近では無人で飛ばしてみようとか、自動でルートを設定して飛ばしましょう、こういう話がどんどん進んでいます。 こちらに対してやはり問題になってくるのは事故・攻撃等で、様々な国でドローンを用いた攻撃が残念ながら発生してしまっています。こちらに対して、現在日本で進んでいる無人機の有人地帯での目視外飛行、俗にいう「レベル4」に向けて安全性を高めていくために様々な議論が当然ありますが、その中の一つとして当然セキュリティも議論するということが必要となってくるだろうという話になります。 IoTに対するサイバー攻撃リスク IoTの診断や、脆弱性に関して我々がやっているところのお話に入らせていただきます。 まず、IoTに対するサイバー攻撃リスクとして考えられるものとしては、データ漏えいと不正操作の2つが代表的です。 データ漏えいは、例えば設置しているカメラから、本来であればアクセスできない人がアクセスできてしまって、機密情報や、本来はアクセスできてはいけないものが見られてしまう、撮られてしまうというもの。不正操作は、先ほど私が冒頭で申し上げたコントローラーやプレゼンテーションの装置がのっとられてスライドがどんどん動かされてしまうとか、ドローンだと本来想定していないような道を走ってしまう、もしくはその状態で本来であれば行ってはいけない場所にどんどん飛ばしてしまうということができてしまう、ということが考えられます。 データ漏えいや不正操作はやはりされて欲しくはないし、今我々としてもこういうものが起きない、安全な状態でITの利活用というものをどんどん進めるということのお手伝いをしていきたいというものになります。 IoTにおける守るべき対象 一般的には、1つ目はIoTのデバイスや装置。 それと通信、例えばこのコントローラーがインターネットに繋がるのであれば、特にケーブル等は入っていないので、やはり無線など通信の経路、これが2つ目です。 3つ目はクラウド。一般的にIoTだとクラウド環境にデータを置いたり、クラウド環境で何か指示を行ったりというものがやはり一般的な設計になっているものが多く、クラウドも当然重要になってきます。 では、一つ一つ見ていきます。 IoTデバイスに対するサイバー攻撃リスク まず、IoTデバイス、装置そのものに関してのサイバー攻撃リスクですが、1つ目は重要情報の漏えい、2つ目が不正なユーザによる操作、3つ目がデバイスの制御のっとり。 これら3つが一番大きなリスクとして考えなければならないものになります。 IoT通信に対するサイバー攻撃リスク 通信のところに関しては、重要情報の漏えいが起きないかどうかという点をチェックする必要があります。 通信のところは一番多くお客様から聞かれるところですが、通信は何を見るのですか？と。例えば、装置どうしが繋がるWi-FiやBluetoothについて、暗号化が正しく行われていないとか、またそこの電波の情報を盗み見る、盗聴することによって、データが抜かれてしまう、重要情報が盗めてしまう、またその逆でそれらへ不正な命令、不正な電波を飛ばすことによって操作がのっとれるということになると、やはり問題になるわけです。通信は重要情報の漏えいということで、暗号とか、ちゃんと正しいところに通信しているかという点のチェックは大事になります。 クラウドに対するサイバー攻撃リスク 最後はクラウドに対するサイバー攻撃リスクです。 こちらに関しては①重要情報の漏えい、②不正なユーザによる操作、③クラウドの制御のっとり、④デバイスの制御のっとりと、この4つが重要なリスクとなってきます。 ①と②に関してはイメージがつきやすいと思います。③のクラウドの制御のっとりについては、クラウド環境は様々各社様から出ていますが、クラウドのシステムを見てみると、ブラウザからいろいろと設定画面を開いたり、もしくはコマンドで設定をしたりして、クラウドのサーバーの環境を自分たちが一番使いやすい形に設定をするわけです。その設定に不備があった場合、つまり本来であれば防がれているはずの通信の内容、分かりやすい例だとポート番号であったり、よく気付かれにくいところですとアクセス用のインタフェースのところ、そこが本来意図した人以外からのアクセスを遮断する形になっていない、攻撃者から簡単にそこの経由からだとアクセスできてしまうという話になりますと、クラウドがのっとられて、そこからデバイスであったり、また重要情報の抜き取りだったりということが発生してしまう、というものがクラウドに対するリスクになります。 サイバー攻撃事例：クラウド経由でのデバイスのっとり これらのリスクが組み合わさった時にどういう問題が起きるかというところで、これは弊社で以前診断をさせていただいて、お客様からも今回のような場面で使って大丈夫ですよとなったものですが、IoTデバイスとしてドローンの例です。 ドローンがクラウドから命令をもらって、クラウドと通信をしてドローンが動いている状況で、我々がクラウド側から入ってドローン側に侵入をして、ドローン側に対して不正な命令を送ると、実際にその時にはドローンを落下させるといったことが実現できているということが、我々のところで確認できています。 IoTのサイバーセキュリティ全体像 IoTのサイバーセキュリティの全体像としては、脆弱性診断というところ。これは脅威分析、アーキテクチャレビュー、セキュアコーディングの次のところにありますが、ここで一般的には作成された製品を診断してくださいと持ち込まれるものが多々あります。しかし当然ながら、例えば何かルールを作る、先ほどの自動車の例では安全な車を作るためのルールを作るという形になれば、よりもっと先のタイミングで安全になるでしょうし、コードの書き方や設計を全部しっかりやっていくことができれば、どんどん前のタイミングでできるのならばその後ろのところで大きな問題が見つかるということもないですし、ちゃんと開発コストをしっかり抑えた状態で安全なものを作るということが実現可能になってくるというものになります。 IoTに対する脆弱性診断 IoTに対する脆弱性診断ということで、先ほどから何度もお話ししたことを今度は我々の視点からご説明しますと、基本的には1つ目がIoTのデバイスに対する脆弱性診断、2つ目が通信に対する脆弱性診断、3つ目がクラウドに対する脆弱性診断、という形で3つ行っております。 1.IoTデバイス脆弱性診断 診断対象はハードウェア、ソフトウェア、インタフェース。簡単に言ってしまえば、ハードウェアはその装置、IoTの機器を実際にバラして、中に基板だったり小さなものが入っていますが、こちらから中のプログラムを例えば抜き出してみようとか、通信のところやCPU、実際に計算をしているところのチップから何か盗めたり攻撃できたりというものがないだろうかというのが1つ目です。 2つ目のソフトウェア診断は、そのCPUの中で走っているプログラムに問題がないだろうかというもの。 3つ目のインタフェース診断は、その外側に開いている口、例えば一般的なものだとUSBポートに何か問題がないかいうもの。 これら3つの診断が、IoTデバイス脆弱性診断になります。 2.IoT通信脆弱性診断 先ほど私が口頭で説明しましたが、通信の暗号化は正しくできているかどうか、認証・認可の不備、ちゃんと送り先は正しいですか、間違ったところに送ろうとしている時にそれを検知できますか、こういった内容になります。 3.クラウド脆弱性診断 こちらも先ほど説明しましたが、設定不備がないかの診断、そして認証・認可、変な人、外部の人、第三者の攻撃者がアクセスできないようになっているかどうか、そして、APIの脆弱性診断、そもそものドローンなどのIoT機器でAPIのインタフェース受付の部分から内部に侵入できるといったようなものがないかどうかというのをチェックします。 経産省の取組み 現在、経産省様と一緒に、IoT機器に対する脆弱性検証という形で行っております。こちらの取組み経由でお申し込みいただければ、先ほど説明したような診断の内容が無料で実施いただけますので、新しい機器であったりとか、最近IoTではいろいろな機器が各社さんからいろいろなアイディアとともに出ているという状況ではありますが、変な攻撃であったりとか、それでアイディアが潰されてしまうとか、そういうことはやはり我々としても望まないので、こういう取組み等を使ってIoT機器が安全な形で、そこに乗っているアイディアを様々な人たちに対して素晴らしいというものをちゃんと宣伝を、ビジネスをやっていけるような基盤というものを一緒に作るという形で、まずセキュリティのチェックを我々と一緒にできればというものになります。 まとめ まず、IoTのセキュリティリスクが増大しております。こちらは、自動車やドローンの例で説明させていただきました。 2番目に、リリース前の脆弱性診断が大事ということです。こちらは、世の中に出てしまうと外からいろいろな人たちから攻撃を受けるリスクがあります。なので、事前にチェックをすることは大事です。 そして、そのためにやはり診断となるとお金がかかるので、経産省様との取組みで安全性・脆弱性の診断をぜひ一度ご体験いただければというふうに私どもとしては考えております。 開催レポートは「Vol.02」に続きます！ 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=SDT0zu9_T8U 連載記事はこちら https://developers.gmo.jp/25547/ https://developers.gmo.jp/25604/

　こんにちは、GMOインターネットグループの國分です。2022年10月7日に開催された、通称Bots（Splunk Boss of the SOC）に参加してきました。Botsがどんなイベントなのか、含め魅力が伝えられたらと思います。 はじめに BotsはSplunk社が主催するイベントです。SplunkはSIEM製品の一つです。SIEMとはSecurity Information and Event Managementの略で、簡単に説明すると様々なログを一元的に管理して、検索出来たり、アラートが設定出来たりするシステムとなります。 Splunk（スプランク）とは サーバー管理者だったり、アプリ開発者だったりすると、ログを見る機会が多いと思います。その際利用するコマンドはLinuxだったら、grepやcat、windowsだったらfindstrを "|"（パイプ）で繋いで諸々ログを確認しているのではないでしょうか。 ログでIPの統計が取りたい！そんな時SIEMがない場合は、 cat access.log | awk -F ' ' '{print $1}' | sort | uniq -c こんなコマンドを打って、統計を取りますが、1つのサーバーの場合は苦ではないのですが、これがロードバランサー配下にWebサーバーが100台あるとなるとどうでしょうか。出来なくはないが、100台のサーバーにログインして、grepだったりcatコマンドを打つことになります。※ログサーバーを準備して一つにログをまとればいいじゃんは、除外！ Splunkがある場合は、 | datamodel Web Web search | stats count by Web.src こんなコマンドで、Splunkで取り込んでいるWebサーバー全部のIP統計が取れます。この構文で、Apache,nginx,IIS等WebのAccessログなら全て検索してくれます。さらに取り込んでいるのがWebログ以外のログもあれば、そのログに対して検索したい文字列で、調査出来ることができます。grepやcatだけでログの調査をしている人にとっては夢のような機能ですよね。 Botsの概要 Splunkで様々なログの検索ができるのを説明しましたが、BotsはSplunkを利用して、回答を導き出すCTF形式で点数を争う競技イベントです。 参加はチーム戦となっており、GMOからはSplunkを普段から利用しているSOCメンバー3名と、サイバーセキュリティを専門とするグループ会社から1名の合計4名チームで参加しました。今回の参加チームは全体で35チームで、チーム人員は最大4名のチームで構成され競い合うことになりました。 各問題はシナリオごとに分別され、シナリオは5つあり、2つのシナリオはSplunkのセキュリティ製品の使い方の問題。3つのシナリオがインシデントに沿った問題となっていました。今回自分ともう一人のメンバーが特定のSplunk有償機能の知見があるので、Splunk有償機能のシナリオ1を担当して、残りの2名のメンバーがインシデント関係のシナリオを解くという作戦で開始しました。 Bots開始 コミュニケーションは完全リモートでの開催だったので、Zoomに集合し、各チームごとにブレイクアウトルームが開設され、そこで会話しながら解いていく形でした。途中経過の点数はスコアボードで確認出来るので、自分のチームがどのくらいに居るのかも確認出来ます。 上位チームのスコア上昇に刺激され各自問題を解いていきます。シナリオ1に関しては知見があったので、ほぼボーナス問題状態で、サクサク回答出来たのですが、シナリオ2の問題は触ったことがない製品の問題だったので、一気に時間が浪費されていき、あと、1時間、いや2時間欲しいというところで終了でした。 9位でした！ まとめ Botsに参加したことで、普段使ったことがない機能の使い方だったり、対象の絞り込みのあたりの付け方もシナリオから学べるので、Splunkをより使いこなしたい方や、セキュリティ製品の導入を検討している人にもおすすめ出来るイベントでした。 また、普段繋がりのないグループ会社の人と一緒のチームで参加することにより、コミュニケーションが促進され、得意分野の共有や、いろいろな意見交換が出来たのは参加してよかった点です。 今後の改善点はお昼をまたいだタイムスケジュールなので、手元で食べれるおにぎりとかパンを用意しておく。シナリオの人員配分を決めておく。この2点を次回参加者へ共有したいと思います。 上位入賞者には商品もありますので、次回開催時には皆様もぜひ参加してみてください。