ウェビナーレポート|6月9日開催、コロナ禍 新しいビジネス様式でのセキュリティ対策とは
ウェビナーレポート|6月9日開催、コロナ禍 新しいビジネス様式でのセキュリティ対策とは

2020年6月9日ウェビナー講演動画 「6月9日開催、コロナ禍 新しいビジネス様式でのセキュリティ対策とは」 コロナ禍を受けデジタルシフトが加速しています。実店舗閉店やテレワークへの移行など、各社ではアナログからデジタルへの移行がこれまでにないほど急速に活発化しています。国内外で急速なECサイトの立上げ、業務システムのオンライン化など目まぐるしく変わる中、セキュリティ対策まで手が回らず、リスクが置き去りな状況も発生しています。攻撃者は、この様な混沌とした状況の中での隙を狙っていますが、ポストコロナを見据えて使い続けられるサービスを選ぶ必要性があります。 CDNetworksは、公開Webサイトのサービスやアプリケーションを脅威から守るWAF(ウェブ・アプリケーション・ファイアウォール)およびBot除去サービスを提供しています。従来型よりもさらに進化したCDNetworksの「クラウド・セキュリティサービス」は、過検知や誤検知も大幅に減り、あらゆるタイプの脅威に対応して、お客様のWebサイトをサイバー攻撃から守る鉄壁となります。 本セミナーでは、グローバルCDNの優れた負荷分散とパフォーマンス向上効果に加えて、DDoS防御も付帯した、あらゆる攻撃にリアルタイムで対応するCDNetworksの「クラウド・セキュリティサービス」について、具体的な利用例を交えてご紹介します。 ========================= ≫ 講演資料ダウンロードはこちら ========================= ■関連サービス:クラウド・セキュリティ ・アプリケーション・シールド(WAF) ≫ https://www.cdnetworks.co.jp/cloud-security/application-shield/ ・ボット・シールド(Bot対策) ≫ https://www.cdnetworks.co.jp/cloud-security/bot-shield/ ご自由に視聴ください。 なお、CDNetworksでは、Web会議(30分ほど)でのサービス紹介も承っております。お気軽にお申し付けください。 ================================== ■お問い合わせはこちら >>お問い合わせフォーム ■関連資料のダウンロードはこちら >> 資料ダウンロード ================================== 株式会社シーディーネットワークス・ジャパン TEL:03-5909-3373(営業

ウェビナーレポート|6月4日開催、ハッキングの脅威から貴社のビジネスと資産を守る方法
ウェビナーレポート|6月4日開催、ハッキングの脅威から貴社のビジネスと資産を守る方法

2020年6月4日ウェビナー講演動画(全編英語) 「ハッキングの脅威から貴社のビジネスと資産を守る方法/How to Protect Your Business from Hackers」 世界的にも未曽有のコロナ・パンデミックに、悪質なサイバー攻撃が多発しています。CDNetworksの「アプリケーション・シールド(WAF)」を活用した手法について、弊社のクラウド・セキュリティ・プロダクトマネージャー Shay Rapaportによるライブオンラインセミナーのレポートです。 ========================= ≫ 講演資料ダウンロードはこちら ========================= ■関連サービス:クラウド・セキュリティ ・アプリケーション・シールド(WAF) ≫ https://www.cdnetworks.co.jp/cloud-security/application-shield/ ・ボット・シールド(Bot対策) ≫ https://www.cdnetworks.co.jp/cloud-security/bot-shield/ ご自由に視聴ください。 なお、CDNetworksでは、Web会議(30分ほど)でのサービス紹介も承っております。お気軽にお申し付けください。 ================================== ■お問い合わせはこちら >>お問い合わせフォーム ■関連資料のダウンロードはこちら >> 資料ダウンロード ================================== 株式会社シーディーネットワークス・ジャパン TEL:03-5909-3373(営業部)

CDNetworks、クラウド・セキュリティWAFサービスリニューアル~Naxsiを採用した新しいWAFで検知性能が向上し運用負荷を軽減
CDNetworks、クラウド・セキュリティWAFサービスリニューアル~Naxsiを採用した新しいWAFで検知性能が向上し運用負荷を軽減

グローバルCDNサービスプロバイダの株式会社シーディーネットワークス・ジャパン(東京都新宿区、以下CDNetworks)は、既存のCDNプラットフォームに組み込まれたクラウド型Webセキュリティサービスであるウェブ・アプリケーション・ファイアウォール(WAF)について、サービス名称も新たに全面リニューアルされたワンランク上のアップグレードサービスの提供を開始したことを発表いたします。 下記にアップグレードされたサービスと機能について説明します。 1.対象サービス クラウド・セキュリティ「アプリケーション・シールド」 (旧:ウェブ・アプリケーション・ファイアウォール/WAF) https://www.cdnetworks.co.jp/cloud-security/application-shield/ 2.サービスアップグレード概要  (1) WAF機能に加えてDDoS防御機能を標準装備  ・DDoS防御機能は、リアルタイムに攻撃を検知/防御する常時ブロック型に  ・WAF機能は誤検知の少ないNaxsiベースのシグネチャを採用、運用が容易に  ・Bot防御対策は、JavaScriptチャレンジ、ヒューマンインタラクション、デバイスフィンガープリントなど、様々な機能により脆弱性を突いた攻撃に対応 *オプション  (2)セキュリティ診断サービスおよびログの提供 *オプション  (3)CDNプラットフォームに完全統合されたセキュリティサービス  ・CDNプラットフォーム上のエッジサーバやリレーサーバ(中継サーバ)上でサービスが稼働  ・別POPへの切り替えや、専用POPを経由しないためパフォーマンスが改善  (4)CDNサービスと共通のカスタマーポータルを提供、管理上の利便性が向上  (5)完全自社開発、自社サポート  ・CDNやDDoS、WAF、Botなど、すべてのサービスを完全自社開発・自社サポート  ・機能アップデートや修正も迅速に対応可能、より高いレベルのサポートを提供 3.提供条件:CDNetworksのクラウド・セキュリティサービスを新規に利用されるすべてのお客さま 4.提供開始日:サービス提供開始済み 本件については、営業担当またはWebサイトよりお問い合わせください。 *電話での問い合わせ:03-5909-3373(営業部) *Webサイトからの問い合わせ:https://www.cdnetworks.co.jp/contact/ =========================================================== LIVEオンラインセミナー開催のお知らせ 「コロナ禍 新しいビジネス様式でのセキュリティ対策とは」 ■開催日程:2020年6月9日(火)15:00-16:00 ■お申し込み:https://pr.cdnetworks.co.jp/event-webinar-security/ =========================================================== CDNetworksは、引き続きグローバル規模のセキュリティ脅威に対抗しつつ、2020年度も引き続き新種を含むさまざまなサイバー攻撃に耐えうるクラウド・セキュリティ・プラットフォームの構築とサービスをお客さまに提供して参ります。 以上 About CDNetworks CDNetworksは、通信パフォーマンス改善の専門家として、世界6大陸に広がる自社配信プラットフォームにおいて、スピード、信頼性、そして安全性の面で最高のパフォーマンスを発揮しながら、企業に向けたネットワーク・インフラと地域ごとの専門知識の提供をサポートしています。CDNetworksは、独自開発の優れた配信技術と配信プラットフォームを活用した大規模なサービス力で国内外のWeb高速化、動画/ライブの高速化、VPNなど企業WANの高速化といったパフォーマンスの改善を軸にクラウド・セキュリティやエッジ・コンピューティングといったネットワーク関連事業の分野にも進出し、特にアジアにおける市場をリードしています。2000年に設立されたCDNetworksは、日本・韓国・中国・シンガポール・インド・イギリス、カナダ、そしてアメリカにオフィスを構えています。 詳細については、https://www.cdnetworks.co.jpをご覧ください。 [本件に関するお問い合わせ先] 株式会社シーディーネットワークス・ジャパン マーケティング担当 増山慈子 TEL: 03-5909-3373 Mail: marketing@cdnetworks.co.jp

[第4回]KSKロールオーバーへの備え~KSKロールオーバー実施前に必ず確認すべきこと
[第4回]KSKロールオーバーへの備え~KSKロールオーバー実施前に必ず確認すべきこと

  第1回はDNSの仕組みとDNSSECについて解説しました。 第2回は電子署名の仕組みとZSK(ゾーン署名鍵)の役割について解説しました。 第3回はZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)について解説しました。 最終回となる本稿では、KSKロールオーバーが実施される前に必ず確認しておくべき事項をお伝えします。   いよいよKSKロールオーバーがJST(日本時間)の10月12日 午前1時(UTC 10月11日 午後4時)に実施されます。 実施前に改めて必要事項を確認し、万全の体制を整えることをお勧めします。     誰が対策するのか   (クリックで拡大)   第1回で触れた通り、KSKロールオーバーの対策を行うのはキャッシュDNSサーバの管理者です。しかし利用者であるユーザも影響の有無について理解する必要があります。     確認事項   KSKロールオーバーに関連して確認が必要な点を記載します。以下のキャッシュDNSサーバ環境はCentOS 7+BIND 9.9.4(chrootなし)を前提としています。     ●DNSSECの検証機能を利用しているか確認する   digコマンドが利用できる環境で以下のコマンドを実行します。「xxx.xxx.xxx.xxx」にはチェック対象のキャッシュDNSサーバのIPアドレスまたはFQDNを入力します。    $ dig @xxx.xxx.xxx.xxx dnssec-failed.org a +dnssec   DNSSECの検証機能が有効なキャッシュDNSサーバであれば、「status: SERVFAIL」の応答となります。「dnssec-failed.org」はDNSSECの検証に失敗するドメインなので、ステータスがサーバエラーとなるのは正常です。    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL   DNSSECの検証機能が無効なキャッシュDNSサーバであれば、「status: NOERROR」の応答となります。DNSSECの検証を行わないため、ステータスがエラーなしとなります。    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR     ●トラストアンカー(ルートゾーンKSK公開鍵)の確認…

[第3回]KSKロールオーバーへの備え~ZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)とは
[第3回]KSKロールオーバーへの備え~ZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)とは

第1回はDNSの仕組みとDNSSECについて解説しました。 また、第2回は電子署名の仕組みとZSK(ゾーン署名鍵)の役割について解説しました。 第3回となる本稿では、ZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)について説明します。     上位ゾーンとの信頼の架け橋となるKSK   ZSKだけでもDNSの応答データが改ざんされていないことは可能です。 しかし応答したDNSサーバが不正なサーバで、DNS応答データ(リソースレコード)も元から不正なデータであれば意味がありません。   KSKはこの問題を解消します。   KSKは上位のゾーンとの信頼関係を結ぶ役割を持ちます。 上位ゾーンに登録されたKSK公開鍵と対になるKSK秘密鍵を利用してZSK公開鍵を署名することにより、ZSK公開鍵もまた、上位ゾーンに信頼されたものとして扱うことができます。     KSKの役割   KSKの役割は大きく分けて2つあります。   ● KSK秘密鍵でZSK公開鍵を署名する ZSK公開鍵は自ゾーンのDNS応答データの検証を行うために利用します。 不正に作成されたゾーンのDNS応答データに対する検証が成功する場合、そのゾーンを署名したZSK秘密鍵/公開鍵もまた不正であるということです。 そこで自ゾーンに対してもう1種類の鍵、KSK秘密鍵/公開鍵を生成します。     KSKの秘密鍵を利用してZSK公開鍵を署名します。 そして自ゾーンにKSK公開鍵、ZSK公開鍵(KSKによる署名あり)を登録します。     しかしこのKSKが不正なものであれば意味がありません。 そのため後述する上位ゾーンへの登録により、自ゾーンのKSK公開鍵が信頼できるものであることを確認できるようにします。     ● KSK公開鍵を上位ゾーンへ登録し、信頼の連鎖を構築する KSK公開鍵が信頼できるものであれば、そのKSK公開鍵で署名の検証が成功するZSK公開鍵もまた信頼できるものとなります。このKSK公開鍵の信頼性は上位のゾーンによって担保されます。     DNSSECを利用する場合はKSK公開鍵のハッシュ値を含む情報「DS(Delegation Signer)」を上位ゾーンに登録します。これは上位ゾーンにKSK公開鍵を登録することとほぼ同義になります。   自ゾーンのKSK公開鍵と上位ゾーンのKSK公開鍵が一致した場合、自ゾーンのKSK公開鍵は信頼できるものと考えられます。上位のゾーンにDSとしてKSK公開鍵を登録できるのは、そのゾーンに対するドメイン管理者でなければできないからです。     信頼できるKSKによって検証が成功したZSKは信頼できる   前述に通り、上位ゾーンのDSにより自ゾーンのKSK公開鍵が信頼できるものとなります。 ZSK公開鍵はKSK秘密鍵で署名されているので、KSK公開鍵で検証します。     信頼されたKSK公開鍵で検証に成功した場合、そのZSK公開鍵もまた信頼できるものと考えられます。 なぜなら信頼されたKSK公開鍵の対となるKSK秘密鍵は正規のゾーンを管理する者でなければ利用できないためです。     たとえば不正に作成された同名ゾーンに信頼されたKSK公開鍵を登録するとします。 攻撃者はこのKSK公開鍵の対となるKSK秘密鍵で不正なZSKを署名する必要がありますが、KSK秘密鍵は公開されていないため手に入れることができません。そこで不正なKSK秘密鍵を自身で生成し、不正なZSK公開鍵を署名することもできますが、不正なKSK秘密鍵と信頼されたKSK公開鍵は対となっていないためZSK公開鍵の検証に失敗します。   ZSK公開鍵の検証に失敗した場合はDNSSECの検証失敗、つまり名前解決が失敗となります。…

DDoS 攻撃に対するリスクマネージメント対策
DDoS 攻撃に対するリスクマネージメント対策

  ITサービスにおいてリスクマネージメントとは、いつ・どこでも発生しうるリスクへのあらゆる対応戦略を検討し準備することです。   ヒューマンエラーのように内部要因により発生する事象であれば、システムやプロセスを改善することでそのリスクを減らせますが、DDoS攻撃(分散型攻撃)のように全く予測できず外部要因(サイバー攻撃)によるものに対しては、その対応にも限界があります。しかしながら、ここで諦めるわけにはいきません。準備をすることで影響範囲を最小化することができるからです。   本ブログでは、明日にでも影響を受けるかもしれないDDoS攻撃に対して、どう準備し対応すべきかについて解説します。     戦略0 : 現状を把握する   まず対応戦略を検討する前に、自らの組織の状態を把握することから始めます。DDoS攻撃は、攻撃者と防御者のインフラおよびアプリケーションの可用性の戦いとも言えます。つまり、自分たちが処理できる範囲を超える攻撃であれば障害となり、範囲を超えなければ通常処理されてそれほどの影響は受けません。   現状把握のチェック方法は、まず会社ネットワークを含めたネットワーク全体のシステム構成図を参照します。バックボーンネットワークからエンドユーザにサービスを提供するサーバまでどのくらいのトラフィックを処理できるのかについて、主にDNS、HTTP/HTTPSなどのサービスを基準にして、例えばL3/L4ネットワーク全体のバックボーンで処理できる容量(例:10Gbps)とL7で処理できるリクエスト数 (例: DNSの 場合200K QPS、HTTP/HTTPSの場合100K RPS)などの数値を把握することで、今後の具体的な対応戦略を検討し、被害範囲を算出するのに役に立ちます。     戦略 1 : ある程度の攻撃に耐えられるサーバ容量の準備   メディアには数百Gbps、1Tbpsの大規模なDDoS攻撃に対する記事が多く出回っていますが、実際は300Mbps ~ 5Gbpsなど小規模の攻撃が大半を占めています。もちろん大規模な攻撃を処理できる体制を準備できればよいのですが、そのためにはたくさんの投資が必要であり、予算と攻撃発生の可能性を考慮しつつ現実的な容量を見極めることが大切です。   では、どの程度の容量を準備すべきなのでしょうか?   正解は「ない」とも言えますが、一般的にイベント時などの急激なトラフィック増加を考慮して2倍程度の容量を準備している場合には、DDoS攻撃に対してはそれよりも2~3倍、つまり通常時の4~6倍の容量を準備するといいでしょう。これにより頻発する小規模の攻撃にはある程度耐えることができるようになります。     戦略 2 : インフラを分散する   DNSやHTTP/HTTPSなどのインターネットサービスは、通信プロトコルがフェイルオーバーに対応しているため、もしもの時に備えて予め2~3重化しておくとよいでしょう。例えば、またDNSの場合は、最小1もしくは2~13までの複数設定が可能ですが、できるかぎり多重化して分散することによって、ネットワークやPoPで障害が発生してアクセスできない状況になっても、他のPoPからサービスを提供することができるため安心です。   $ dig cdnetworks.co.jp ns cdnetworks.co.jp.     86400       IN            NS           ns1.cdnetdns.net. cdnetworks.co.jp.     86400       IN            NS           ns2.cdnetdns.net .ns1.cdnetdns.net.     86400       IN           …

[第2回]KSKロールオーバーへの備え~電子署名とZSK(ゾーン署名鍵)の役割について
[第2回]KSKロールオーバーへの備え~電子署名とZSK(ゾーン署名鍵)の役割について

  第1回はDNSの仕組みとDNSSECについて解説しました。 第2回となる本稿では、DNSSECの仕組みのひとつである署名、そして署名に利用される鍵のひとつZSK(ゾーン署名鍵)について説明します。     DNSSECに利用される公開鍵暗号   DNSSECにはZSKとKSKの2つの鍵が利用されることを前回お伝えしました。どちらも公開鍵暗号という仕組みの鍵で、電子署名として利用されます。まずは公開鍵暗号について理解を深めましょう。     RSA暗号と電子署名   ● DNSSECの電子署名に利用される暗号アルゴリズム DNSSECの電子署名は複数の暗号アルゴリズムに対応しています。 http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml   本稿では比較的理解しやすく、また広く使われているRSA暗号を利用したケースを説明します。     ● 閉める鍵と開ける鍵が異なる RSA暗号では秘密鍵と公開鍵の2つの鍵が利用されます。   これらは暗号化と復号に使われますが、秘密鍵で暗号化したデータは公開鍵で復号することができ、公開鍵で暗号化されたデータは秘密鍵で復号ができるという特性があります。別の言い方をすれば暗号化に利用した鍵では復号することができません。   公開鍵は名前が示す通り利用者に公開され自由に利用できる鍵です。一方で、秘密鍵は公開鍵を作成した人が厳重に管理して外部に漏れないようにします   機密情報を送って欲しい場合は、秘密鍵と公開鍵のペアを作成し相手に公開鍵を送ります。そして相手から公開鍵で暗号化した機密情報を送ってもらいます。   仮に悪意を持つ人が公開鍵を取得し、暗号化された機密情報を傍受したとしても復号できません。公開鍵で暗号化された機密情報は、もう一方の鍵である秘密鍵でなければ復号できない(極めて困難である)からです。     ● 秘密鍵で暗号化して電子署名とする 機密情報をやり取りするのであれば前述の通り、公開鍵で暗号化して秘密鍵で復号する必要があります。しかしその逆の処理、つまり秘密鍵で暗号化し公開鍵で復号するケースがあります。それは電子署名です。   まず秘密鍵と公開鍵のペアを作成し、公開鍵を誰でも取得できるようにします。   相手にデータを送る際、そのデータを秘密鍵で暗号化して署名として付与します。   署名付きのデータを受け取った人は署名を公開鍵で復号します。署名を復号すると暗号化する前の情報、つまり取得したデータと同等の情報が得られます。これにより2つのことがわかります。     まず1つは公開鍵を公開している人が送信したデータであるということ。手に入れた公開鍵で復号できるのはペアとなる秘密鍵で暗号化されたデータだからです。秘密鍵は公開鍵を公開している人が厳重に管理しているはずなので、秘密鍵で暗号化できる人、すなわち公開鍵を公開している人が送信したデータであると考えられます。     そしてもう1つは通信途中でデータが改ざんされていないことです。データを改ざんしたとしても、署名という形で暗号化されたデータを同じように改ざんすることはできません。そのため、データと署名を復号したときのデータで不一致が発生し、署名の検証に失敗します。   このように署名の検証に成功すると、得られたデータが改ざんされていないことが分かります。この役割を果たすのがZSK(ゾーン署名鍵)です。     ZSKだけでは足りない信頼性   ZSKがあればDNSの問い合わせをした先のサーバの応答であること、そして応答データが改ざんされていないことが分かります。しかしこれだけでは安全とは言えません。   ●問い合わせ先の権威DNSサーバが信頼できるものとは限らない 「example.com」のDNS情報を応答するのは「example.comゾーン」の情報を持つ権威DNSサーバです。その権威DNSサーバ情報は上位の「comゾーン」の権威DNSサーバからの応答で知ることになります。つまり上位ゾーンの権威DNSサーバの応答を改ざんすることができれば、「example.comゾーン」を持つ不正な権威DNSサーバへ誘導することが可能です。   ●権威DNSサーバは他者のドメインのゾーンファイルを作成することができる…

最適なSSL/TLS化の設定ガイドライン

  Googleがhttps化(SSL/TLS化)されていないWebページについて「Not secure」メッセージをChrome上で表示させる取り組みがいよいよ7月にスタートします。今後httpの場合にはアラートメッセージがもれなく表示されることになります。   そこで、これからはログインなどの入力フォームを利用していない単純なホームページであっても、基本的にhttpsに対応しておく必要があるでしょう。   SSL/TLS化する際にネックとなる複雑な問題については、以前のブログで解説をしていますので、是非そちらをご覧ください。(https://www.cdnetworks.co.jp/blog/6144/)   SSL/TLS化については、特にSSLサーバ証明書(certificate)の準備からプロトコルおよびcipher(暗号)の設定が複雑です。そこで本ブログでは、SSL/TLS化の設定時に最適なSSL/TLSプロトコルおよびcipherの設定構成について解説します。     無料でApache WebサーバにSSL/TLSサーバ証明書を構築する   SSL/TLSの利用には、まずSSLサーバ証明書の設定から始めなければなりません。ただし、同時にCDNを利用する(している)場合には、比較的簡単にこれを構築することができます。   Webサーバ(オリジン)に直接httpsを構築するには、comodoやdigicertのようなSSLサービス(暗号化通信)の利用が一般的ですが、最近はほぼすべての最新ブラウザとの互換性を維持しつつ無料でサービスを提供するLet’s Encrypt(https://letsencrypt.org/)を利用するケースが急増しています。   <画像1>   ここではApache Webサーバを運用する前提で、Let’s Encryptを設定する方法について解説します。 Let’s Encrypt を利用してSSLサーバ証明書を設定する方法はとても簡単です。まず、gitで関連ファイルをインストールしてスクリプトを実行するだけで完了です。    git clone https://github.com/letsencrypt/letsencrypt  cd letsencrypt/  /etc/init.d/httpd stop  ./letsencrypt-auto certonly –standalone  vi /etc/httpd/conf.d/ssl.conf  /etc/init.d/httpd start <表1>   次に<表2>は、viでssl.confを設定する際に、追加する必要がある内容の例です。 <表1>のスクリプトで生成したSSLサーバ証明書関連ファイルの場所を「SSLCertificate*」の指定子で指定します。    <VirtualHost www.example.com:443>  ErrorLog logs/ssl_error_log  TransferLog logs/ssl_access_log  LogLevel warn  SSLEngine on  SSLProtocol TLSv1.2 -SSLv2…

ワンタイムパスワード(OTP)、 今すぐ使い方をマスターしよう

  私たちはインターネットで銀行振込サービスを利用する時や株の取引をする時など、重要な作業をする時にワンタイムパスワード(OTP)を使用します。たまに不便を感じたりもするOTPは、絶対に使わなければならないものなでしょうか?   答えは「Yes」です。しかも「今すぐ」にです。   本ブログでは、なぜOTPを使わなければならないのか、そしてCDN利用時におけるカスタマーポータルサイトへアクセスする際のOTPの使い方についても解説します。     完璧なセキュリティ対策はない   もし、今この記事をお読みになっている皆様のパソコンやスマートフォンの画面を、自分だけでなく他人が遠隔で一緒に見ていたとしたらどうでしょうか?また、ログインをするために自分が入力したID/PWの情報がリアルタイムでハッカーの画面にも転送され表示されていたとしたら?   もしや、最新バージョンへのセキュリティパッチを済ませているから、シマンテックのようなアンチウィルスソフトがインストールされているから、「私は絶対に大丈夫」と思っていませんか?もちろんある意味それは正しいですが、必ずしもそれで完璧だとは言えません。   なぜなら、パッチが公開済のセキュリティ脆弱性のみならず、まだ知られていないセキュリティ脆弱性(これを「ゼロデイ」と言います)も世の中にはたくさん存在するからです。もし「我が社のセキュリティ対策は完璧で安全だ」としても(絶対そんなことはありえませんが)、巧妙に偽装された偽サイトにアクセスし誤ってあなたのID/PWを入力してしまったり、さまざまな社会工学的(Social Engineering)技法を通じてあなたのID/PW情報を攻撃者が奪い取る可能性もあるためです。この場合、どんなに難しいパスワードの設定をしても意味がなく、結局のところ完璧なセキュリティ対策は存在せず、追加対策が必要と言えるでしょう。     正解は2要素認証(2Factor Authentication)を使用する方法   既存のID/PWは1要素認証(1Factor Authentication)と言い、これにOTPなど追加認証を結合したものを「2要素認証」、または「2ステップ 認証」と言います。最近では「トリプル認証(Triple)」、または「多要素認証(Multiple Factor)」や「マルチステップ認証」という言葉も使用されています。   概念としては次の画像のように、すでに知っているもの (ID/PWなど)以外にもIDを所有している本人であることを追加で認証できるツールで認証することを意味します。例えば指紋や虹彩(目)のような生体認証や所有するスマートフォンを通じた使い捨てパスワードの発行(OTP)などです。     画像 : 多要素認証の概念     OTPのメリットとは   ではOTPはどんな「メリット」があるのでしょうか。   1、パスワードは一定時間(30秒程度)のみ有効で再使用ができないため、万が一情報が漏れても安全 2、一般的なデジタル認証に比べて安価 3、時間同期化方式(TOTP:Time Based OTP)※1、およびイベント基盤(HOTP:HMAC Based OTP)※2の両方に対応、ほとんどがTOTPを使用 4、スマートフォンアプリなど別のデバイスを利用したH/W OTP※3の場合には無料で使用できるので便利かつ安全   ===== ※1 一定時間(30秒程度)が経過するたびに新しいOTPが生成されるアルゴリズムで、一定時間が過ぎると使えなくなり、改めて生成したOTPを使用しなければならない方式 ※2 イベント基盤のアルゴリズムでログインするたびに新しいユニークなパスワードを生成する、クリックして生成されたOTPをパスワード入力枠に入力して認証を受ける方式 ※3 APP利用ではなくデバイスを利用する、デバイスの購入が必要で値段が高い上に紛失の恐れがあり不便と言われている方式 =====     CDNetworksは、PCI DSSのセキュリティポリシーに基づき、すでに数年前からなどにアクセスする場合に、既存のID/PW/IP/Keyなどいくかつの要素に対する認証を行っており、その他にも追加でOTPを使用して厳格にアクセスコントロール・ポリシーを守っています。  …

Interop Tokyo 2018/Security World
Interop Tokyo 2018/Security World

Interop Tokyo 2018/Security World CDNetworks講演情報 タイトル  迫りくる新たなWebセキュリティ脅威に備えるために今すべきこととは?  ~進化するボットやAPIサーバ攻撃など、CDNで実現できる未来型防衛対策の最前線 概要  Webサイトは常に「セキュリティとパフォーマンス」の課題がつきまといます。本セッションでは、強固なWebセキュリティ対策とパフォーマンス向上の双方をCDNの活用で簡単に効率よく実現できる方法をご紹介するとともに、高度化するボット攻撃対策、新たな盲点とされているAPIサーバ攻撃など、Webセキュリティ脅威の最新動向とその防衛術についてもご紹介いたします。 講演  株式会社シーディーネットワークス・ジャパン テクニカルコンサルタント マネージャ 中原嘉隆 会場/時間  6月15日(金) / [ED-20] 16:00~16:40 受講料 終了しました。ご登録・ご来場ありがとうございました。 お申し込み https://reg.f2ff.jp/public/application/add/667   ■イベント概要   イベント名 Interop Tokyo 2018 ~はじめよう。次のネット社会 日時  2018年6月13日(水)~15日(金) 会場  幕張メッセ(国際展示場/国際会議場) 主催  株式会社ナノオプト・メディア ホームページ https://www.interop.jp/ [print_link]