雑記帳

■ Box World Tour 2015に参加した

渋谷ヒカリエで開催された、Box World Tour 2015に参加してきた。

現在弊社では、Boxを導入しようとしている。Boxは、企業が使用する場合に必要となる共有の管理やセキュリティ、監査、シングルサインオンなどの様々なエンタープライズ向け機能があるクラウド型のストレージサービスである。

現在、色々と検証中ということもあって、他社の事例が聞けることを期待して参加した。

発表されていた事例は、早稲田大学、GREE、楽天、第一三共だった。それぞれ、なぜ導入したのか、という話はだいたい似通っていて、どこも同じような課題を抱えているのだなと思った。

主な課題は以下のようなもの。

• ストレージ不足
• ファイルが探せない（検索できない）
• アクセス制御が難しい
• 外部の人との共有の問題
• バージョン管理

Boxは、これらの課題を解決できるという。弊社も同様な問題を抱えているので、個別の事例は参考になった。

話を聞いていて、注目したものについてピックアップしてみる。

充実したAPI

APIを使って管理・監査を楽にできるというのは、とても大きいメリットだと思った。特に印象に残ったのは、GREEの事例で、社外の人と共有するものについては、申請をしてもらうことで、それの共有範囲が申請された範囲を超えているかどうか、定期的にAPIを使ってチェックしているという所。もしチェックがパスしなかったら、即座に共有が停止され、メールにて通知されるという。こういうハックができるのは素晴らしい。

全てのアクティビティについてのログ

誰が何に対してどんな操作を行ったのか、といったログが全て参照できる。これは、セキュリティに関する各種認証（PCI DSS、SOC、Pマークなど）に対応するためには必要な機能。また、監査を行うことができるシステムもあるとのこと。

SaaS系は比較的ログが弱いと思うので、他社はもっとがんばって欲しい。

データ移行は大変

これは弊社でも同じ悩みがあって、大量にあるファイルをBoxに持って行くのが大変だと思った。 FTPを使った事例が紹介されていたけど（余談だが、BoxがFTPに対応しているというのはすごい）、自分がテストした範囲では、WebDAVも結構行けると思った。

ストレージ利用ポリシーの定義が重要

Boxの共有や権限付与の方法は、従来とは違う考え方になるため、従来の使い方をそのまま持って行こうとすると、却って不便になりそう。最初にそれなりにポリシーを定義しておかないと、後で苦労しそう。

また、Box以外のストレージの使い方も決めておかないと、他のクラウドストレージを使われて管理できてなかった、というような不幸なことも起こる可能性がある。ストレージはすべてBoxに統一すると決めて、かつ、ユーザがBoxを使いたく成るように管理者がお膳立てをするのが重要。Boxが不便だからという理由で、他のストレージを使われるのは困るため。

StreemFS

PCのローカルにBoxのファイルを同期することができる、Box Syncというのがあるが、これの代わりになるもの。StreemFSという技術を使って、ローカルのファイルシステム上に実際のファイルのエイリアスが見えるようにして、あたかも実体がそこにあるかのように見えるとのこと。これを使うと、大量の更新されたファイルの同期によって、帯域が食われるようなことが無くなりそう。まだリリースされていないようなので、期待したい。

その他、かなり魅力的な新機能がいくつか紹介されていて、今後にさらに期待できそう。

まとめ

参考になる他社事例と、新機能などについて知ることができて、有意義だった。 弊社でも、Boxをどんどん有効活用していきたい。

■ TOTPを冗長化するN個の方法

TOTPとは、Time-based One Time Passwordの略で、Google Authenticatorで使われている技術のこと。Googleアカウントを始め、今ではいろいろなところで、多要素認証の一つの要素として使われている。

TOTPを扱うのには、主にスマートフォンにアプリケーションを入れて使われることが多い。しかし、スマートフォンは落として割ってしまったり、どこかに無くしてしまったり、機種変更をしたりと移ろい易く、認証コードが使えなくなってしまうことがある。

そういうこともあるため、各種システムでは、多要素認証をリセットする手段を用意していることが多い。 だが、サービスごとに違うリセット手順を実施するのは面倒なので、できればリセットせずに復旧する方法をとりたい。

ということで、自分が考え付く幾つかの方法を紹介する。

認証コードを同期できるアプリケーションを使う

Google Authenticatorは、認証コードをアプリケーション内に保存するのみなので、アプリケーションにアクセスできなくなると、利用できない。しかし、幾つかのアプリケーションは、認証コードをクラウドを使って同期して、複数のデバイスで利用できるようになる。

• Authy
• 1Password

1Passwordは、元々パスワードを管理するためのツールで、後からTOPTに対応したということもあり、認証に関する情報を一元管理できるので、大変便利だと思う。

複数のデバイスに登録する

認証コードを初期設定するときは、二次元コードをスマートフォンのカメラで読み取って行うのが一般的である。このコードを読み取るときに、複数のデバイスで同時に読み取ることで、認証コードの冗長化できる。

これについては、以前に書いた記事を参照のこと。 http://muramasa64.fprog.org/diary/?date=20111212

認証コードを保存しておく

先に紹介した記事でも触れているが、仕組み上*1、この認証コードを保存しておいて、後から再度使うことができる。例えば、認証コードを印刷しておいて、金庫にでもしまっておくこともできる。

また、画像ファイルとして、EvernoteやDropboxなどのクラウドストレージに保存しておいても良いだろう（そこにアクセスする方法が失われないことが前提にはなるが）。認証コードは、必要になるアカウント自体の情報と関連付けずに保存しておけば、比較的安全かと思われる。パスワードと同じ扱いで良いと思う。

まとめ

認証コードの仕組みさえわかってしまえば、それを冗長化したり、保存したりするのは難しくない。上記に紹介した方法以外でも、自分に合った方法で冗長化すれば良いかと思う。

■ [AWS] AWSへのフェデレーションログインとBacklogを連携する

最強のセキュリティでAWSマネジメントコンソールにアクセスする方法で紹介されている「ヌーラボ社のBacklogと連携しており、アクセス記録が残る仕組みになっています」について、問い合わせがあったようなので、詳細について書いてみたいと思う。

社内で作ったAWSアカウントを管理するツール（以下、管理ツール）からログインするときには、シングルサインオン（以下、SSO）をしている。ここでは、SAML認証という認証方式を使っている。

SAML認証

ここでは、説明に必要な最小限の仕組みを簡単に解説する。

ユーザIDを管理している、アイデンティティープロバイダー（以下、IdP）として、Active Directoryを使っている。これと、PingFederateというID連携を容易にしてくれるシステムを使って、自社制作の管理ツール（Webアプリケーション）の認証を実現している。

SAML認証は、Webシステムの認証情報を一元管理できるのが特徴の一つで、AWSをはじめ、Google Appsや、Office365、Dropbox、Slackなどのサービスが対応している。エンタープライズ向けのWebサービスは、結構な割合で対応している。

また、SSOを実現できるという特徴もある。

ブラウザでWebアプリケーション（サービスプロバイダ、SP）にアクセスした際に、SAML認証をしようとしてSPからIdPに対して認証のリクエストが行われる。その際、まだ認証されていない場合は、たとえばHTMLのフォームを使ったパスワード認証を実施する。IdPで認証できたら、その結果をSPに連携する。

SPから認証の要求があったときに、すでに認証されている状態である場合には、再び認証要求はなされずに、認証済みであることが、SPに連携される。それによって、ユーザとしてはセッションが有効である間は、複数のSPへのアクセスに対して、IDやパスワードを入力する必要はなくなる。

Backlogとの連携

管理ツールからAWSにログインするときにも、SAML認証を行う必要がある。AWS側は、IAMの機能としてSAML Providerというのがあり、そちらを設定すれば使うことができる（これについても詳細は別途書こうと思うが、今回の話にはあまり関係ないので省略）。

SAML認証はブラウザベースでの認証が想定されている方式*1で、認証をする際にはIdPに対して、HTTPSのリクエストを発行している。

このリンクをクリックすると、以下のようなダイアログが表示される。

「Exist Backlog Issue Key」とラベルがあるところに、Backlogの課題キーを入力すると、Backlog APIを使って、そのキーに該当する課題の情報を取得し、課題の件名をDescriptionに埋めるようになっている。これが有効でないと、ログインするボタンが押せないようになっている。

また、サーバ障害による緊急対応など、Backlogに課題がない場合は、Descriptionに任意の理由を記入することで、ログインする際に自動的に課題を作成するようにもなっている。

「Send」ボタンを押すと、ajaxを使い、管理ツール側に対して、必要な情報とともにリクエストが発生する。管理ツールでは、入力されてきた情報をログに書き込み、いつ、どのログインユーザが、どの課題を元に、どのAWSアカウントに、どのロールでログインしたのかが記録される。

Backlogの課題キーの部分は、Backlogの当該課題へのリンクになっているので、チェックも容易である。

それと同時に、ブラウザで別ウィンドウを開いて、AWSへのログインリクエストを送信する。ログインリクエストは、SAML認証を経て、AWS Management Consoleにログインに至る。

ポイントは、管理ツールを中心にして、IdPやBacklog、AWSとの連携を行っているという点だろう。AWSへのログインをするためのURLは、ブラウザから送られてくるパラメータに応じて、管理ツールから発行されるようになっているし、そのリクエストを出す前に、管理ツールを経由してBacklog APIを使い、課題の有無のチェックや、新規課題の追加を行っている。

なお、Backlog APIを実行するユーザは、管理ツールで管理されているユーザである。Backlogに管理ツール用のユーザを作り、そのユーザのAPIキーを発行している。このユーザは、すべてのBacklogプロジェクトに参加している。

まとめ

SAML認証は、HTTPSをベースに利用できるID連携のためのプロトコルであるため、Webアプリケーション間で連携を行うのは、比較的容易である。Web APIを使えるサービスは、このような連携ができるため、アイデア次第でより便利に利用できるだろう。Backlogだけでなく、他のサービスとも連携して、もっと便利にできればと思う。

■ [AWS] AWS Account Numberを取得するツールを作った

昨年の12月に「AWS Account Numberを取得するN個の方法」という発表を行った。

この時の発表内容を元に、実際にAWS Account Numberを取得するツールを作った。 https://github.com/muramasa64/aws-account-number

gemでインストールすれば使える。

% gem install aws_account_nuber

使い方

単に実行すれば、APIを実行したAWSアカウントのAWS Account Numberが取得できる。

% aws_account_number
012345678901

例によって、thor-awsを使っているので、Credentialsは、環境変数や、--profileオプション（~/.aws/credentialsの情報を参照する）、-kと-sオプションでの直接指定も可能である。

デフォルトでは、defaultセキュリティグループの情報を使って取得している。権限の問題で、セキュリティグループへのアクセス件がない場合に、IAM Userの情報から取得することもできる。サブコマンド iamuser を指定する。

% aws_account_number iamuser
012345678901

また、CloudFormationを使う場合は、cfnを指定する。

% aws_account_number cfn
012345678901

当たり前だけど、どれも結果は同じ。

速度比較

% time aws_account_number cfn
012345678901
aws_account_number cfn  1.15s user 0.20s system 51% cpu 2.617 total

% time aws_account_number iamuser
012345678901
aws_account_number iamuser  1.21s user 0.21s system 65% cpu 2.175 total

% time aws_account_number security_group
012345678901
aws_account_number security_group  1.19s user 0.21s system 25% cpu 5.403 total

何回か実行してみたけど、だいたい上記と同じぐらいの時間がかかった。SecurityGroupが一番遅いのは意外。