ID・パスワードが盗まれても不正ログインされない対策とは。SaaSのセキュリティ対策最前線

カテゴリー: イベント
このエントリーをはてなブックマークに追加

2019年3月14日~3月15日、Sansan株式会社が主催するカンファレンス「Sansan Innovation Project 2019」に、IIJはブースの出展とミニセッションの登壇をしました。
ブースでは、Sansanの認証セキュリティを強化するIIJ IDサービスを紹介しました。

ミニセッションでは、セキュリティ強化の必要性について、デモを交えてお話しました。内容を少しご紹介します。

ID・パスワードによる情報保護は限界

Sansanをはじめとする、Office 365やSalesforceなどの様々なSaaSサービスにより業務の効率は格段に高まりました。クラウドの特性を活かし、リモートワークによる業務に効果的に活用するケースも増えてきています。一方で、情報漏えいなどのセキュリティリスクへの不安が共通の課題となっています。
たとえば、利用するサービスの脆弱性を突いた攻撃によりパスワードを盗まれて悪用されるセキュリティ事故や、フィッシング詐欺・ビジネスメール詐欺に起因してアカウント情報を騙し取られる情報漏えい事件は後を絶ちません。


(クリックすると別ウィンドウで拡大表示します)

ID・パスワードが盗まれてもログインされない対策が必要

被害を抑えるにはどうしたらよいでしょうか?盗まれたパスワードによる不正ログインを防ぐためには、そのIDがシステムで誤って認証されるのを水際で防止するのが効果的です。認証のセキュリティを強化し、仮にID・パスワードが漏洩してもログインされないようID・パスワード+アルファの対策をとることが理想的です。

方法のひとつに、社内のネットワークからのアクセスしか認めない「IPアドレス制限」があります。SaaSにアクセス可能なIPアドレスをあらかじめ制限することで、オフィスネットワーク以外の不正なアクセスをシャットアウトできます。IPアドレス制限は導入が容易ですが、細かな制御を行うのは難しく、たとえば外出中の営業や、社外にアウトソースしたコールセンター、あるいは在宅勤務の方が利用しにくくなってしまうなどの制約があります。また、SaaS本来の利便性を享受できなくなってしまいます。

そこで「IPアドレス制限」の応用として「IPアドレス制御」があります。社外からアクセスする必要があるユーザを限定させる方法です。ただし、これだけでは社外からアクセスするユーザのセキュリティを守っていないままとなります。

そこで別の対策として「多要素認証」があります。ID・パスワードというユーザの「知っている要素」に加え「ユーザしか持っていないデバイス」、または「ユーザの生体情報」を用いて本人確認を強化する方法です。これにより本人確認がより強化され、セキュリティは高まりますが、安全であるはずの社内ネットワークでも追加認証を要求されますと利便性が下がってしまいます。

よって、「IPアドレス制御」と「多要素認証」を組み合わせ、社外ネットワークにいる時だけ「多要素認証」を要求するといったアプローチが効果的です。


(クリックすると別ウィンドウで拡大表示します)

複数のSaaSアクセスを一元管理できるIIJ IDサービス

利用しているSaaSはひとつだけだよ、という方は現在では少なくなりつつあります。多くの企業は、インターネット上の魅力的なSaaSをいくつも組み合わせて利用することで競争力を高めています。一方管理者の視点では、サービスごとにID・パスワードを設定し、セキュリティを管理するとしたら、利用できるサービスの数には限界があるでしょう。SaaSを業務に活用するためには、ID・パスワードや認証機能を一元的に管理し、より多くのサービスを便利に手間無く利用できる環境が欠かせません。

IIJ IDサービスでは、各種クラウドサービスに対して、不正ログインの検知やログイン防止ができる多要素認証機能のほか、Sansanをはじめとするクラウドサービスを効率良く利用するためのID管理機能とSSO(シングルサインオン)機能をクラウド型で手軽に利用できます。

ユーザが複数のサービスを利用する際、それぞれのサービスに別々にログイン操作を行うのは非常に面倒です。IIJ IDサービスを使うとユーザはログインを一度で済ませることができ、ストレスなく業務を遂行できます。管理者の視点でも複数のサービスで個別にセキュリティを制御するという非現実的な運用を行う必要もありません。月額200円で、複数のSaaSへのシングルサインオン、AD連携、多要素認証の機能を利用できます。また、ADと連携して自動同期し、かつ、セキュリティ制御を自動強制できますので、ADFSの構築は不要です。

特設サイトから、ぜひIIJ IDサービスで変わる世界を体験してください!

☆セミナーのご案内☆
Active Directory運用担当者さま必聴セミナー
Active Directoryで実現する Windows 10運用からOffice 365 認証まで

お問い合わせ

IIJパートナーフォーラム2019を開催!

カテゴリー: イベント, パートナー
このエントリーをはてなブックマークに追加

今回は、2019年2月21日に開催された「IIJパートナーフォーラム2019」の様子についてお届けします。

本フォーラムは今年で8回目となり、今年も沢山のビジネスパートナー様にお越しいただきました。
会の中ではIIJサービスの最新情報をお伝えすると共に、2018年度を通してサービス拡販に特にご尽力いただいたパートナー様4社を表彰させていただきました。

20年以内には機械に人の意識を移植することが実現できる

最初のプログラムとなる特別講演では東京大学大学院工学系研究科 准教授 渡辺正峰氏をお招きし、人工意識という大変興味深いテーマについてお話しいただきました。

早ければ20年後には、機械に人間の意識をアップロードすることが実現できるかもしれないと語る渡辺氏。
講演冒頭では人の意識に関わる実験に触れながら、生成モデル、意識の自然則といった概念から”意識”とは何であるかを解説。その上で客観にとじている既存の科学の研究方法では”意識”が物に宿ることを証明することは非常に困難であるとし、主観を観測するための機械と脳を接続する方法などを具体的に解説しながら、人工意識の可能性について存分に語っていただきました。
理論的背景を伴う高度な内容でしたが、参加者の皆様は人工意識がどのように実現できるのか、という関心深いテーマについて熱心に聴講されていました。

「IIJ Partner of the Year 2018」の発表

フォーラム後半では「IIJ Partner of the Year 2018」アワードの表彰式が行われました。
今年は多くのパートナー様の中から「Partner of the Year」と「ビジネスイノベーションアワード」の2部門で4社が受賞されました。

株式会社ソフトクリエイト様は、昨年の「IIJ Omnibusサービスアワード」受賞に続き、2年連続での受賞となります。

Partner of the Year

株式会社ソフトクリエイト 様

「SCLINEネットワークサービス IIJ Omnibus」を積極的に展開、テレワークインフラの整備など、幅広いお客様ネットワークの課題を解決し、最も素晴らしい実績を残されました。IIJのサービス開発への技術協力を含め、クラウドサービスの価値向上に尽力いただきました。

ビジネスイノベーションアワード

株式会社システムインテグレータ 様

基幹業務パッケージ「GRANDIT」の基盤としてIIJ GIOを採用。クラウドならではの柔軟性・拡張性とIIJ GIOの信頼性を組み合わせることにより、お客様価値を高めました。

株式会社ディーバ 様

経営管理・予算管理ソリューション「DivaSystem SMD Cloud」の基盤にIIJ GIO with Microsoft Azureを採用。グローバル企業に欠かせない、迅速に展開可能なSaaSサービスを構築されました。

株式会社トヨタシステムズ 様

企業向けネットワークサービスにおけるSACMの採用を含む長年の協業により、トヨタグループをはじめ様々なお客様の広範なITインフラをサポート、ビジネス拡大に貢献いただきました。

2019年度に向けてますます拡がるIIJパートナープログラムのネットワーク

IIJパートナープログラムへのご加入数も大幅に拡大、日々弊社ビジネスの拡大にご貢献いただいております。また、IIJパートナーポータルのご利用も徐々に広がっております。よりよくご活用いただけるよう機能追加も進めておりますので、まだお使いになっていないパートナー様はこの機会にぜひご活用いただければと思います。

今後も様々な皆様にご満足いただけるような支援体制を整えながら、パートナーシップを末広がりに推進していきますので、どうぞよろしくお願いいたします。

IIJパートナープログラムにご興味のあるお客様は、担当営業またはお問い合わせフォームまでお気軽にご連絡ください。

2017年度パートナーアワード受賞特典のご紹介

昨年度のパートナーアワード受賞特典として、受賞パートナー様のソリューションをご紹介するプロモーションサイトを公開させていただいております。

IIJパートナーソリューション

 各社ソリューションのご紹介

Partner of the Year:USEN ICT Solutions様

 「とらのあな」が高アクセス対応のネットワーク環境を構築 – 運用管理の大幅な効率化を実現

IIJ GIOアワード:テノン・システムコンサルティング様

 製薬系や医療機器系のニーズに応える業務システムをクラウド基盤ごと提供

IIJ Omnibusサービスアワード:ソフトクリエイト様

 クラウド、アプリケーション、ネットワークをワンストップで提供する「SCLINE IIJ Omnibus」で、”ひとり情シス”の負荷も軽減

LaIT・セキュリティサービスアワード:リコージャパン様

 ネットワークやIT環境の運用に課題を抱える中小規模企業の味方「NETBegin BBパック Next」の魅力とは

(IIJパートナー事務局)

Office 365導入の光と影。強化しておくべきセキュリティ対策とは?

カテゴリー: Microsoft, イベント
このエントリーをはてなブックマークに追加

Office 365には個人情報を含む従業員のデータや、社外への持ち出しを禁止している機密情報など多くの重要データが集約されています。近年では働き方改革の一つとして多くの企業が在宅勤務などのリモートワークを導入、オフィス以外で業務を行うことが増えており、セキュリティ対策についてOffice 365の標準機能だけで十分とはいえなくなりました。働き方改革を浸透するにあたって、社外へ持ち出される端末の紛失や情報漏えい対策など、リスク管理の強化は、重要なポイントのひとつです。

IIJはOffice 365のセキュリティ強化についてのセミナーを不定期で開催しています。これからOffice 365の導入を検討されている企業から、既に導入済みの企業まで聴講いただける人気セミナーで、12月の開催でも国内3拠点を巡り多くの方に聴講いただきました。

明暗をわけるOffice 365「メールセキュリティ」対策

アプリケーションが豊富なOffice 365の導入により、場所やデバイスを選ばずに業務ができるようになる一方で様々なリスクも発生します。たとえば“迷惑メール”からのウイルス感染、“宛先間違い”による誤送信、“添付ファイル間違い”による情報漏えい、突然の障害など『事故が起きてからでは遅い』課題は事前に対策が必要です。

IIJが提供するOffice 365 with IIJならOffice 365と組み合わせて利用することで、Office 365だけでは足りない機能をカバーし、情報漏えい対策や誤送信対策、外部脅威に対するセキュリティをより強化することができます。

多層フィルタにより脅威メールの検知率を向上させ、迷惑メールをブロックすることでマルウェア感染のリスクを低減。誤送信対策では、Office 365にはない添付ファイルの自動暗号化機能でメールの誤送信、情報漏えいを防ぎます。
また、Office 365の障害、メンテナンスで利用ができない時でも、ご利用中のメールアドレスを変更することなくメール送受信を可能とし、業務の継続性を確保します。
その他にもOffice 365に関するお悩みから、お客様固有の課題などIIJによる手厚いサポートでメールセキュリティの運用を支援しています。

入り口だけでは防げない、大事な情報を守る為の「エンドポイント」強化対策

ビジネス環境や社員のリテラシーは企業により異なり、脅威の侵入経路も様々です。クラウドサービスを活用した入り口対策のみでは、脅威の検知や感染経路調査の観点で限界があります。最新マルウェアは急速に増え続けており、サンドボックスによる検知や、従来型のアンチウイルスソフトでは未知のマルウェアに対処できなくなっているのです。
そんな課題を解決すべく、IIJでは昨年10月からIIJセキュアエンドポイントサービスの提供を開始しています。

ウイルスの多くは、メールの通信から内部ネットワークへ侵入し大事な情報を持ち出して外部へ送信します。感染経路はメール以外にもWEB 、USBメモリなど多様であり、侵入したウイルスすべての経路は最終的にサーバやパソコンといったエンドポイントに行き着きます。
IIJセキュアエンドポイントサービスは、検知ロジックの異なる複数のアンチウイルスソフトを併用することで、「既存のウイルス」から「未知のウイルス」も含めてブロックします。

また、合わせて提供しているクラウド型IT資産管理機能では通常のPC管理はもちろん、持ち込み、持ち出しなどの内部不正対策から、外部脅威対策、ライセンスなど一元管理が可能なため、万が一ウイルス感染が起こってしまった際に、「どのPC」で感染し、「誰が」「いつ」「どんな操作をしたのか」、という一連の感染経路を操作ログから確認できます。
このようにIIJのサービスではエンドポイントセキュリティを強化し、Office 365を安全に使いこなすためのセキュリティ対策をサポートします。

『中小/中堅企業』向けにOffice 365のセキュリティ強化を圧倒的にお得に!

Office 365には業務上の機密情報や社員の個人情報などの大切なデータが集約されています。Office 365だけでは足りないメールセキュリティを強化し、大切なデータを守りませんか?
Office 365 with IIJは、Office 365の月額料金そのままで、セキュリティ機能をプラスしてご利用いただけます。

脅威はすぐそこに!マルウェア対策とIT資産管理を支援するIIJのエンドポイントセキュリティ

マルウェアなどの脅威は入口対策で防御するのと同時に、エンドポイントセキュリティを強化することで、万が一入口を突破されてもそれ以上の外部送信や不正を遮断し被害を防ぐことができます。
IIJセキュアエンドポイントサービスなら脅威の流入経路や影響範囲の追跡、内部不正の状況を可視化し、クラウド上で一元管理することでお客様の負荷を大幅に軽減できます。

お問い合わせ

コンテナ技術でクラウドの運用はどうなる? ー 後編

カテゴリー: VWシリーズ, イベント, 統合運用管理
このエントリーをはてなブックマークに追加

2018年11月15日、株式会社インターネットイニシアティブで「マジセミ(参加者の役に立つ“本気”の情報提供セミナー)」が開催されました。セミナーのテーマは「Docker、Kubernetesなど「コンテナ技術」のクラウドサービス(AWS、Azure、GCP)での活用と、コンテナ時代のシステム運用」。本記事では、弊社福原が「クラウド運用の行く末はいかに!?」をテーマに、仮想化技術であるコンテナの運用現場について語りました。

前編から続く

今日の本題はコンテナです。コンテナがなにかについては別のセッションで触れられているので、私からは触れないですが、私が今お話したような流れで、従来のノリでいけるのかが僕自身もまだまだ疑問なところがあるんですね。

そこで、我々はどうしていくのかについてこれからお話しします。おもしろいなと思うんですが、オンプレ、IaaS、コンテナのイメージについて、みなさんが描いている絵が微妙にみんな違います。この絵が正しいかどうかは置いておきますが、みんな違うんですよね。変遷でいくと、オンプレやIaaS、PaaS、SaaS、コンテナがあります。

ざっくり運用者の視点から見るとどうか。開発者ではなく、運用者から見ると、オンプレは実は楽なんですよ。IaaSはまあまあわかりやすい。コンテナになると正直よくわからないとという気がします。

順次見ていきますと、例えば、オンプレの構成は変わらない。上から下まで全部管理対象だし、自動化しようと思ったらがんばればできるのがオンプレの特徴です。

スライドの63パーセントという数字は「オンプレがこの先増えますか? 減りますか?」というアンケートの答えですね。63パーセントが「たぶんこのままオンプレ使います」と言っています。意外と「へ~」ですよね。

オンプレの監視や運用について

オンプレの監視をどうするか? ご存知のとおりですね。UOMでも監視できますが、JP1やZabbix、Nagiosなど、いろいろなオープンソースもあって、ずっとオンプレの環境に対して見にいくので、当然、従来型の仕組みでできます。

オンプレの運用は? プロセスやサービスの再起動とかクラスタの切り替えですね。クラスタサービスとか入っているかもしれないですけども。

こういったものを、いわゆる手順書ベースでやっていくのが基本的な考え方です。最近はRBAでコマンドラインを自動化していく感じになってきました。

地味にオンプレで面倒なのは、閉域接続をどうするのか。だいたいオンプレですから、自分たちの箱の中にものが作られていきますからね。

そこに対して我々みたいにアウトソーシングする人たちは、リモートから入らないと仕事できないので、接続する回線を作らないといけない。一般的には閉域接続や広域イーサなどでつないでいきますけど。

各社のモニターツール活用事例

こちらはIaaSです。ご存知のとおり、スライドでは年率20パーセントくらいで成長することが示してあります。20パーセントではなく、もっとすごい数字を示しているところもたくさんあります。成長しているという意味ではみなさんのご理解のとおりですね。

IaaSは作る側からしてみたら動的に構成が変わったりすることもあって、いい面もあります。運用から見て、いいところはOSより下は基本的に見ない。

また、意外とAPIが出てくるので、自動化はしやすいです。コマンドラインじゃなくてAPIを実行すると、いろいろできるのが大きな特徴です。

IaaSを監視しようと思ったら、あまり気にしなくても従来型の監視システムでだいたいできます。OSが見えているので、エージェントを突っ込んだり、リモートでログインができますね。オンプレかどうかは、あまり考えないですね。あまり問題にならないです。

強いて言えば、VMwareなどを使った場合にハイパーバイザーの監視をどうするのか? 弊社はVMwareベースの「VWシリーズ」を提供しています。

こういったESXiに対するログの監視は、APIベースで取ります。リソース、ログ、構成情報を取るのなど、今はこういったものも必要ですね。

だんだんレイヤーが最近になってきました。PaaSやSaaSなど、言い方はいろいろありますけど、こうなってくるとどうなるのか? 実は先ほど出てきたような監視ツールで監視はできないです。なぜか? それぞれ各パーツでしかないことを考えると、そもそもログインでできないからです。

そのため、我々としては、どうしようとしているか。AzureMonitorやStackdriver、CloudWatchなど、各社がいろいろなモニターツールを出されていますけど、そういったところと連携させようとしています。

例えば、メールやAPIで取り込む。CloudWatchはUOMでは標準的にメトリックを取れたりします。こういったものがないとPaaSやSaaSを見られな いです。

ただ、ご注意いただきたいのはSaaSやPaaSを細かく下まで見る必要があるのか? ということが本質的にあります。オンプレと同じように全部見なきゃいけないというのは少し間違っています。そこはご留意ください。

閉域接続のメリット・デメリット

それでは、IaaSの運用の話に戻します。基本的にはリモートログインベースでやっていくのはいいと思います。オンプレと同じです。しかし、APIが出ていますから、各社のAPIをうまく使っていくほうが楽だと私は思っています。

我々としては今ちょうど作りかけたところではありますが、年明けくらいに各社のクラウドをCLIベースで実行できるものを順次リリースすることにしています。コマンドラインでオペレーションする時代ではないと思っているので、こういうふうにしていくのは必然だと思っています。

そしてIaaSの接続が難儀です。AzureやAWS、GCPなどがあったときに、これとどうやってつなぐのかがなかなか難しいんですね。例えば、IIJだとExpressRouteでAzureにつなぐことや、DirectConnectでAWSをつなぐことはもうできています。

そのため、監視の仕組みであるUOMもこういったものに接続すべく、近々リリースします。マルチクラウドへの接続はやはり必要ですよね。

ただご存知の方もいらっしゃいますが、これらの接続はコストが高いんですよ。コストを重視するなら、VPNという選択もなくはないですが、VPNはなかなか設定が面倒くさいです。できないことはないですけど、ちょっとハードルが高いと思います。

ちなみに「IIJ GIO」というブランドでやっています。プライベートリソースをVMwareベースで作っているのがありますが、こういったものはIIJの中だと標準接続でプライベートでつながれています。これは宣伝ですけど、そんなこともやっています。

コンテナ管理を自動化する重要性

そしてついにコンテナまでたどり着きました。最近の話ですね。いろいろなものがどんどん変えられる。すぐ作って潰せるのがいいところですよね。コンテナ自身が管理してくれます。この状況下でコンテナをどうやって監視しますか? 

結論ですが、従来の監視じゃ無理です。やってやれないことはないですが……。スクラッチ&ビルドされるものに対して、監視を1個1個すれば可能だと思います。

しかし、何の意味もないですよね。今日のコンテナの講演を聞いていただいたら、みなさんわかると思います。違う方式を考えざるを得ないと思います。

じゃあどうするか。コンテナはコンテナ自身で見てくれますから、コンテナ自身が見てくれた情報を集めるものが必要じゃないですか? 自分で見に行く時代はそろそろ終わりだと思います。

コンテナから来る矢印が、今までと違って、逆になっているんですね。これは情報を拾ってあげる受け口がないと運用できなくなりませんか? さらに運用するときには従来型のログインする作業はできないことはないですが、やはり難しいんじゃないかと思います。

そもそもコンテナ自身が管理してくれているんですから、いっそのこと任せてしまったらどうでしょうか? 運用屋の私が言うのもどうかと思いますが、たくさんコンテナの接続を切りますから、従来通りでやるのは無理です。1個1個手順書作るのは絶対あり得ないですよね。

管理してくれているコンテナ自身を制御する方向に持っていくなど、もっと上段の管理が必要。すなわち統合的な運用を考えないといけないなと思っています。

そういったコンテナへの接続はどうするのか。インターネットで接続するのもいいかもしれないですけど、やはり閉域がいいですよね。ずっと運用をやってきた僕としてはやはり閉域が一番だと思います。

マルチクラウド時代の運用管理をどうするか

こうして、いろいろな状況を見てきました。クラウドは多様化しています。そして、複数のクラウドが使われます。

これは弊社のお客さんのアンケートです。73パーセントくらいのお客さんが「いろいろなクラウドを一緒に使います」とおっしゃっています。我々のお客さんなので、IIJ GIOを使ってくれると一番ありがたいんですけど、そういうお客さんはあまりいないんです。いろいろなクラウドを一緒に使っています。

なぜか。「各社さんがいろいろな長所があるじゃないですか」「どこか1択より、あれとこれを使いたくなりますよね」。当然だと思います。どうしてもマルチクラウド化は避けられないんですね。

そこに今日のお題です。コンテナが入ってきたとなると、冒頭の絵と似ていますが、オンプレやメガクラウドがあって、その上にコンテナなどがあります。いろいろなところに行ったりするわけですよね。オンプレまで降ってくると、とてつもなく複雑ですよね。運用屋としてはあまり考えたくない状況ですね。

簡単に言えば、各社さんでできることがバラバラになってきています。それぞれできることが違うので、これをどうにかまとめる仕組みが必要ですね。

マルチクラウド時代の運用管理をどうしていくか。ざっくり絵で描きました。統合管理をするためのツールを置かないとやはり厳しいでしょう。

その下にぶら下がらなきゃいけないものは各メガクラウドやオンプレ、そのほかに拠点やVPN設備もあるので、いろいろなものにつながらないといけないです。

なぜならばシングルで使う人は絶対いないですし、オンプレもなくならないですから。運用管理する人たちはどこかを見ていればよいですが、絶対ならないです。統合的に見ないと疲弊します。

どうやるかと言うと、IIJはネットワークの会社なので「IIJ Omnibus」という接続サービスがあります。こういったネットワークサービスと組み合わせていただくことでいわゆるメガクラウドと接続できて、オンプレとも接続できます。WANの構成でも、拠点でも接続できます。そういったところまで考えていかないと、この先の運用者はいろいろなツールを見なきゃいけないですからね。

今日のセミナーでご紹介があったいろいろなツールは、みんなそれぞれ個性があってすごくいいと思います。しかし、それを全部知っていて、運用するかと言うと難しい気がします。

サブスクリプションとサポート統合

そして、地味に忘れちゃいけないのはサブスクリプションですね。今日課金の話は出なかったんですけど。各社のクラウドを使っていると課金処理は、みんなバラバラなんですよね。円建て・ドル建てなどに対応しなければならない。

それを都度、従量で計算するのは非常に大変です。そのため、こういった課金管理の部分まで含めて、統合的に処理しないと、情報システム部門の現場の仕事で課金管理のエクセルがまた増えるわけですね。こういうものまで含めて統合的にやらなければいけない。

そして最後はサポート統合です。当然、契約はみんな別ですから、一般的にはメガクラウド全部とサポートの契約を結ばなきゃいけなません。こういったサポートも含めて統合的にやらなければいけないと思います。

各社へのハンドリングを自分でするのか、誰かにお願いするかも気にしていく必要があるでしょう。

今後もSaaSでさまざまな機能を実装

今日はいろいろなお話をさせていただきましたが、IIJではこういった機能をSaaSというかたちでご提供しております。まだまだ進化途中ではございますが、放っておくとSaaSなのでどんどん機能が上がります。

当然サプスクリプションモデルでやっていますので、いろいろな必要な機能を厳選してパッキングして販売させていただくかたちでご提供しています。

もしかすると、競合他社の方も今日ご参加のみなさんの中にいらっしゃるかもしれないです。私は運用者はみんな仲間だと思っています。OEM・リブランドみたいなかたちでこの基盤そのものをご提供させていただくビジネスもやっています。

今日は、いろいろな情報がありましたが、まだまだ僕らも作り切っていないところもありますので、「一緒にやっていきたい」などの話がありましたら、ご検討いただければなと思っております。

これで私の話は終わりにさせていただきたいと思います。どうもありがとうございました!

(会場拍手)

サービスのご紹介

IIJ統合運用管理サービス(UOM)
IIJ GIOインフラストラクチャーP2

IIJのクラウドサービスに関するお問い合わせ

コンテナ技術でクラウドの運用はどうなる? ー 前編

カテゴリー: イベント, 統合運用管理
このエントリーをはてなブックマークに追加

2018年11月15日、株式会社インターネットイニシアティブで「マジセミ(参加者の役に立つ“本気”の情報提供セミナー)」が開催されました。セミナーのテーマは「Docker、Kubernetesなど「コンテナ技術」のクラウドサービス(AWS、Azure、GCP)での活用と、コンテナ時代のシステム運用」。本記事では、弊社福原が「クラウド運用の行く末はいかに!?」をテーマに、仮想化技術であるコンテナの運用現場について語りました。

コンテナ技術でクラウドの運用はどうなるか

福原亮:みなさんこんにちは。私からは「クラウドの運用はどうなっていくのか」についてお話しさせていただきます。

誤解のないように申し上げますと、ここで言う運用はいわゆるコンテナ自身の「運用」だけじゃなくて、システム運用全般のところについての「運用」と捉えていただければと思います。

まず自己紹介です。私はもともとデータセンターのオペレーターをやっていまして、監視・運用だけで今まで生きてきました。

このスライドに載っているバスは僕の自家用車で、今年の夏に会社の人間とキャンプに行ってきた写真です。8月の末だったんですけど、なぜか栗がたくさん落ちている。
夏なんですけど、よくわからない。「そんな寒かったっけ」と思いつつ(笑)。

週末はそんなことをしながら、今日ご紹介するIIJのサービス開発の責任者をやっています。

まず「アウトソーシングって何だったっけ?」ですが、これは釈迦に説法かもしれません。ご存知ない方もいらっしゃるかもしれませんけど、IIJはけっこう前からアウトソーシングをやっていまして。かれこれ10数年、僕が入社する前からやっているんですよ。

ここでは細かくご説明しませんが、いわゆるマルチクラウドの運用管理サービスです。まさに流行りですね。それから自動オペレーション。最近はRBAと言ったりします。クラウド型なのでSaaSで提供しています。この中身が一体何なのかを、今日これから順次ご紹介をさせていただきます。

年間に1,000万件ものアラート

まずこちらのスライドです。1,000万件というのは、私どものサービスで受けているアラートの年間件数です。いつも申し上げるんですが、あまり誇れる数字ではないですね。アラートが1,000万件も来る。「1日何件来てんだ!?」 みたいな。

僕のメールボックスには、日にだいたい5,000~1万通くらい来ますけど、それよりはるかに多い(笑)。とんでもないアラートが出ているのが事実ですね。そうなってくると人件費や管理をどうするかが問題になってくると思います。

我々の現場がこうなっているとは言いにくいですが、みなさまもそうかもしれません。システムがどんどん増え続けていて、IT人口が減少していますから。

意外とあるあるな話なんですが、これが今日のテーマであるコンテナ技術が入ってくるとどう変わるのかを見ていきたいと思います。

状況をもう1回見ていくと、システムはAWS、Azure、Google。IIJも「IIJ GIO」というクラウドサービスをやっています。それからオンプレもありますよね。こういったものがどんどん増えていく中で、当然メールや基幹系のWebのシステムなどが、どんどん増えていく実感はあるかと思います。

もう1つ、IT人口は減少しています。日本の総人口もそうなんですけど、ITの人口がどんどん減っていく。減っていくだけじゃなくて高齢化している。どんどん高齢化していくことが統計として挙がっています。

こんな中でITシステム運用をしている現場が何をしているのかと言うと、エラーのあったメールを一生懸命管理するために、エクセルに細かく転記をしている。でも、たまに漏れて上司に怒られるみたいな。意外とこういうことやっていませんか?

最近お客様のところへお邪魔してサービス紹介をするときに、「転記やっていませんか?」と聞きます。転記をやっている会社もいますけど、それすらやっていない会社が圧倒的に多いです。

メールボックスにたくさんアラートメールが溜まっているだけの方が一番多いです。がんばろうとしてエクセルにするんだけど、がんばりきれない。「どうしようかな」という人のほうが圧倒的に多いです。

必要かもしれないですけど、効率的ではないです。ましてや生産的な活動でもない。こんなことは単純に面倒ですよね。

アラートの実態には3つの特徴がある

どうしても疑問になるのは、「我々のようなITの現場にいる人間はこのままでいいんでしょうか?」ということです。答えはわかっていて、いいわけないです。

そもそもシステムの保守・運用が何をしているのかを見ていくと、残念ながら障害が発生してしまいましたと。その障害への対応がいるのか、いらないのかを仕分けして、調査して、「どうしようかな」と検討して復旧させる。一般的にはこんな感じですよね。

アラートが発生してしまう理由を私どもの中で調査してみたんですが、大きくこんな感じで3つくらいに分かれます。

開発している人が「ごめん、メンテナンスしてた」。アプリケーション担当者に「ごめん、バグが入ってたのでアクセスするといろいろ出てしまう」。データベースが落ちてしまったので「ごめん、同じ障害だった」。そんなことがたくさんありました。

それがどれくらいなのかというと、なんと97パーセント。けっこう驚愕の数字だと思います。先ほど申し上げた、年間1,000万件あるアラートの97パーセントは、970万件です。この970万件はいらないんですよ。なぜなら対応が必要ないから。対応しなくていい。

振り分けた結果、捨てているだけのものがこれだけありました。本質的には障害を出さなければいいし、アラートは削減すればいい。そのとおりなんですけど、意外とそうじゃない現場のほうが多かったりするんですね。心当たりがありませんか?

ホワイトリスト的な形式でアラートを判定

我々がどうしてきたかと言うと、いらないものはいらないので、できれば機械的に捨てたい。僕らはフィルターと呼んでますけど、まず最初にそのアラートがいるのか、いらないのか、要否の判定をシステムで機械的にやっていきます。

これはファイアウォールに例えて言うと、ホワイトリスト的な形式になります。運用者からすると僕的には画期的だと思うんですけどね。なぜか? 基本アラートは全部受け付けるのが普通ですから。

でもこの仕組みは全部受けて全部捨てるんですね。なぜならホワイトリストだから。まず、ファイアウォールみたいに必要なものだけ、パーミットしてあげます。

もしくは、あらかじめメンテナンスとわかっているのであれば、ある一定期間特定のアラートを一番目に要否判定します。

続いて重複の排除。データベースでたくさん出てしまうものに対しては同一の障害ということで、5分単位でキュッとまとめてしまう。つまり、重複排除をしてあげましょう。

障害を検知したら誰かに伝える、教える、通知することなどは、最後にやらなければならない。そして、エクセルに書くのではなく、チケットを起票することは別に機械でもできますよね。そういうことをIIJとしては取り組んできています。

どんな感じかと言うと、これは画面のイメージですけれども。メールとかで入ってきた障害、AWSのpingの障害、そしてプロセスの障害などがあります。こうしたときにどうしますか? 

リストの一番上はなにも指定してない。捨てる。メールから来ても捨てます。リスト二番目のpingの障害が来たらどうしますか? 「メールと電話をしてください」「メールとSlackを送ってください」みたいな。

どこにどういう連絡をするかをホワイトリスト形式で登録してしまえばいい。発想としてはけっこう安直です。

障害回復の代表的な手順

フィルタリングできたとして、次はどうやって障害を回復するか。IIJはずっとアウトソーシングをやってきましたけど、そんな中の代表的な手順はスライドのとおりです。

Windowsのサービス起動を説明するまでもないですけど、Web画面でサービスのストップ、スタートを押すのがWindowsのサービス起動です。

Unixのプロセス起動は、スタートスクリプトを叩く手順だけです。こんなことがアウトソーシングの中では蔓延しています。

このスライドは、とある月で実際にどれくらいの手順書を使ったかを集計したリアルな数字です。横軸は手順書の種類で、縦軸は実行回数です。

一番左を見てください。実行回数が4,500回くらいになってますね。つまり1本の手順書を月に4,500回も実行した。じゃあ一番右側と言うと1回だけ実行したというのが一番右側です。

しかも、横軸は全部足しても180本しかないんです。ちなみに、IIJで今アウトソーシング等々を請け負っていて、だいたい数百社のお客さんがいらっしゃいます。手順書の数は5万本くらいあるんですよ。5万本あって180本しか使ってなかった。

これを比率にすると99.6パーセントを使ってない、ということですね。

結局手順書の内容がこういう状況なので、プロセスを再起動するのであれば、リモートでログインしてプロセスの再起動をすればよくないですか? ワードできっちり起こした手順書でもやることですから。

RBAは、けっこう前から流行っていて、去年か今年くらいでピークになっていますが、たぶんPBAほどはいらないんですね。RBAが悪いとは言ってないですが、実際に必要とされている機能はさほど多くないんです。

アラートのフィルターでビジネス規模拡大

こんなことをずっとIIJではやってきていまして。その結果、どうなっているのかを示した数字がこれです。

左側はアラートをフィルタリングした結果を指したものです。フィルターに引っかかった97パーセントがゴミでしたが、全部はフィルターが無理でした。しかし、94パーセントくらいは機械的にバサッと消せました。

でも、まだ残りが6パーセントあります。この6パーセントの中の半分くらい、つまり48パーセントが機械的にオペレーションできた。トータルで見ると97パーセントくらいが自動化したことが今のIIJの実態です。

ビジネス的にはどうだったか。その結果として、お客さんの運用対象ノードが今10万台くらいありますが、アラートの97パーセントを削減しています。

一番いいことは1人あたりが5倍のお客様を持てるようになったことです。届いたアラートのいる・いらないを見ていたのを、機械に置き換えた。単純オペレーションを機械に乗せましたので、やらなきゃいけない目の前のオペレーションに専念できるようになった。

やはりアウトソーシングビジネスをやっている僕たち、もしくはアウトソーシングではなくインソース型であっても、この手のアラートの仕分け作業をされている方はたくさんいると思います。そういう方々のビジネス規模や生産性を上げることができると思います。

機械化した結果、思わぬことがいろいろありました。例えばこちらでは、チケッティングのシステムが連動しています。オペレーションは機械でやっているものですから、いつ・どこで・誰に電話したことや、オペレーションしたことなどが、タイムラインで自動で書けるようになりました。ログを持っていますからね。

監視もしっかりすると、監視しているキャパシティーデータをもとにして未来を予測してみることなどできます。

これはAIではないんですが、予測してみることもできます。

月次報告書を作るのが面倒くさいのであれば、レポーティングも自動でできます。

いろいろなデータがあると、こんなことがホイホイできるようになってくる。言われてみればそりゃそうですよね。人がやると大変なんですけど、機械だとすぐにできてしまう。

オンプレ、IaaS、コンテナのイメージは若干異なる

こんなことをやって生まれてきたのがIIJ統合運用管理サービスです。「UOM」と僕らは呼んでいます。昨日今日で完成したのではなくて、いろいろな失敗をしながら気がついたらここまで成長してきた。このサービスそのものを今日ご紹介せずに、ここで終わりにします。

後編に続く