雑記帳

■ 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だけでなく、他のサービスとも連携して、もっと便利にできればと思う。