share facebook facebook twitter menu hatena pocket slack

2015.07.16 THU

パスワードを入力させるSaaSは全て脆弱という考え方

WRITTEN BY 齊藤 愼仁

シンジです。そんなこと言ったらなんにも使えないじゃ無いか!というのはその通りなのですが、cloudpack – CTO鈴木は「自社のADからSSO(シングルサインオン)できないサービスは原則採用しないもん!」というポリシーを持っています。これって実際のところどうでしょうか?今回はcloudpackがどうやってSaaSを採用するかという内部資料の一部を特別に公開して、SaaSの選び方について考えてみます。

cloudpackは原則、AWSなどへのログインにパスワードを使いません

こちらは、「最強のセキュリティでAWSマネジメントコンソールにアクセスする方法」でご紹介した通りなので詳細は割愛しますが、社内ではパスワードを使うシチュエーションは、「パソコン/Macにログインするときと、SSOするときのみ」です。どちらにしてもADのユーザーIDとパスワードしか使いません。まさしくSSOです。SAML非対応サービスについてはPing IdentityのPingOneを経由します。最終的にはこれも辞めて、全部SAML経由、そしてSSOするときの認証でIDとパスワードを使っている部分を、Kerberos認証にしたいです。

そして、パソコン/Mac達のパスワードの定期変更も実施しているのですが(ADが3ヶ月に1回の変更をユーザーに求めてくる&Slackで通知が来るが)、 もはやこれって無意味なんじゃと思いながら、でもPCIDSSの要件にあるのでやっていたりもして。。。完全なSSO環境で、これ効果あるのかなぁ。。。なんて思ったり。どう思いますか?

パスワードを定期的に変える方が脆弱な気がしている昨今です。

専用URLを発行するサービスは安全か

これはどういうことかというと、

https://会社名とかのサブドメイン.saas.com/

これが安全と言えるかという話です。Cookieのドメインが変わるというのは、セキュリティには寄与するとは思いますが、実際のところどうなんでしょうか。

ただ、企業向けのSaaSを使うと、基本的にこうなりますよね。なので、サブドメインの部分が知られなければ、IDとパスワードを使った辞書攻撃などを受けにくくなるかもしれません。

とはいえ分かりやすい名前で登録するケースが多いでしょうから、簡単に予測ができるでしょう。いろいろな会社名やサービス名で試して、ログイン画面が開けば第一関門突破ですね。じゃああんまり意味ない?とは思いませんが、一定の抑止力にはなる?

これ自身にセキュリティ効果を強く期待しない方が良さそうなのかもしれません。

SaaSによっては「IPアドレス制限」がかけられるものもありますので、もし自社からしかアクセスしないということであれば、これを登録することで、より効果を得られるかもしれません。ただし、登録できるIPアドレスの数に制限があることが多いですから、これは予め確認した方が良さそうです。

IDとパスワードを公開しても安全か

例えば、AWSにもアカウントとパスワードがあります。それ以外にも、アクセスキーやシークレットキーもありますね。これをブログやGithubで公開しても安全か、という極端な話です。

結論は、危険というか、完全にアウトです。

ではAWS以外はどうでしょうか。Dropbox、Google Apps、Box、Evernote、salesforce、他にもいろいろありますが、それぞれ想定してみて下さい。

IDとパスワードを使わない、SAML2.0でのSSO縛りは安全ですがリスクもあります。自社のIdPなどのサーバーがダウンしたら、全てのSaaSにアクセスできなくなるわけです。冗長構成をどう組むか、構成しなければなりませんね。

また、全てのアカウントをSAML通信に出来るわけではありません。とあるSaaSは、管理者のみはパスワード認証も併用するような仕様の物もありますし、AWSでいえばrootアカウントは別途管理する必要があります。

結論。IDとパスワードは現在のところ無くならないので、徹底的に管理してあげないといけないなぁ、と思いました。
みなさんはどう管理されてますでしょうか。これ大変な事だと思います。

通信が暗号化されていれば安全か

PCIDSS v3.1の観点から見ると、

  • TLS1.1
  • TLS1.2
  • それ以外は許しましぇーん(対応計画書だしなさーい)

とかなんとかなので、これに従います。SSL3.0はオワコンなのです。社内のいろんなアプリの通信が、「SSL3.0」とかだったりしたときには阿鼻叫喚です(とはいいつつも、cloudpackでは既に全てをTLS1.2で実装済みまたは計画完了済みです)

IDaaSは安全か

今年の6月に「LastPass」が攻撃を受けて、マスターキーが漏れるという情報漏洩が発生していました。結果的には漏洩したデータを価値のあるものに複合化することは困難で、影響は無いと言っていましたが、ユーザーの反応でなかなか面白い物があったので転載します。

“不満があるならば,サービスの利用を止めた方がよいでしょう … 私たちのインターネットは,国家レベルの支援を受けた攻撃に晒されています。すべての行動,デジタルデバイス内のすべてのエントリ,接続するインターネットのすべては脆弱です。その中で可能な最善の策が,今回起こったことなのです … クレーマたちのやっていることは,良心的な企業に対して,問題の発表を止めさせることになります。誰にもメリットはありません。何が起きたかを発表することによって,他の企業は,周辺防御でそれに応えることができるようになります … インターネットに接続すれば,誰も攻撃から安全ではありません。報告の透明性によってのみ,適切なセキュリティは達成できるのです。”

  • 怖いなら使うな(んな無茶な)
  • 企業は透明性を確保して公開しろ(それは確かにそう思う)
    ということですかね。 だったらパスワードを求めてくるSaaSを辞めたらいいよ(鈴木CTO)ってことで、cloudpackでは、

「Ping Identity」の「Ping Federat」と「PingID」を採用しました。これの特徴が、

  • Ping Federateは、オンプレミス環境に展開出来る(閉ざされたVPCで展開出来る)ので、こちらも閉ざしたActive Directoryと認証情報のやりとりを、個人のブラウザ経由で完全に閉域の中で行える。(外部SaaSとの通信はSAML2.0でだけ)
  • PingIDの多要素認証での通信では、そこにパスワードなどの「やばい情報」が含まれていないため、3G回線だろうがフリーWifiだろうが全く怖くない
  • 多要素認証なのに数字の入力が無い。楽。Apple Watchも対応。
  • 価格がやたらと安い(コスパ面で最高)
  • SAML2.0か、OpenIDConnectがSaaS側で使えれば、とりあえずSSOできちゃうという、お手軽感
  • SaaS側の対応SSOプロバイダにPing Identityの記述が無くても、なんやかんやでSSOできちゃう
  • Ping Identity Japanの方達がやたらといろいろに詳しい(サポートが最高)

もちろん有名どころのOktaやOneLoginなどなども比較しましたが、Ping最高。

多要素認証は安全か

現時点では最も効果的なセキュリティ対策でしょう。cloudpackの場合は、「PingID」でシュっと持ち上げてやるだけです。数字を入れる時代は終わったのだ。

だがしかし! もっと面白そうな物を教えて頂きました(Ping Federateの福家さんから)

専用のハードウェアをUSBメモリの1ポート殺す感じで刺しておくと、それが2要素目の認証になって勝手にサインインしてくれるという優れもの。もはやPC紛失したら2要素認証の意味が無いんじゃないかとも思える製品ですが、スマホなどに頼っている以上、これらの紛失リスクもあるわけで、PCに刺しっぱなしならPCごと無くさない限りは大丈夫なのかな?

ユーザーの利便性は上がりそうだけど、セキュアとは言えないかもしれませんね。(だったら抜いておけばいいじゃないか→そっちの方が無くしそう)

一応その製品をご紹介します。

YubiKey Family of Products | Strong Two-Factor Authentication for Secure Logins | Yubico
https://www.yubico.com/products/yubikey-hardware/

SaaSを使う前に机上で評価してみましょう

何にでも基準が必要です。 cloudpack SecurityWhitePaperにも記述がありますが、独立行政法人情報処理推進機構 セキュリティセンターから発行されいてる、

中小企業のためのクラウドサービス安全利用の手引き http://www.ipa.go.jp/files/000011595.pdf

こちらがカジュアルにセキュリティ評価できる良い資料です。PDFの最後のページにチェックリストがあります。

cloudpackでは、これをSOC2の監査で使っています。例えばこんなかんじ。
(下記資料は非公開資料です、今回だけ特別に一部をご紹介します)

適合していなければ採用出来ない、という主旨では無くて、リスクを洗い出して認識しましょうというのが主旨です。実際のところ、cloudpackではこれ以外の資料も使って総合的に判断しています。(cloudpack SecurityWhitePaperに参考があります)

きちんとリスク評価すれば、「使えるSaaSか」判断できます。そしてリスクを社内共有しましょう。そうすることで、クラウドのスピード感を保ちつつ、企業としての事業継続性を高めることができるかもしれません。

SaaSは安全に正しく便利に使いましょう〜

元記事はこちら

パスワードを入力させるSaaSは全て脆弱という考え方

齊藤 愼仁

cloudpack 社内インフラ担当、情報セキュリティ責任者。HPCを経て現職に至る。無類の猫好きで、すだち君という名の猫を飼っている。