DroidKaigi2018で発表した内容の補足とスタッフとしての役割

DroidKaigi2018でスピーカーとして「認証と認可と君と」というタイトルで話してきました。

speakerdeck.com

また、併せて微力ながらもスタッフとしてお手伝いさせていただきました。

スピーカーとして

さて、技術的なところは今後ステップバイステップでコードともに説明していくと思うので、本稿ではエモいパート（序盤と終盤）のところのフォローをしようと思います。

序盤のエモい部分

序盤は何故、@ken5scalがこのテーマを攻めようと思ったかをFintechと業界絡めて話しています。 金融APIに求められるセキュリティ～APIDays Paris講演より｜2017年2月号｜金融ITフォーカス｜刊行物｜NRI Financial Solutions

上記の記事にある通り、Fintechという金融ビジネス上のイノベーションで、注力されようとしている分野は３つあると言われています。それが1) AI 2) Blockchain 3) オープンAPIです。その中でも特にオープンAPIに注目しています。企業単体ではできない・持てない価値を交換する窓口および経路として、シルクロードのような存在になると思っているからです。

そんなAPIを安全に守るため様々な対策が必要なのですが、そこで重要なのが認証と認可です。アクセス制御として第一の入り口となる認証・認可こそオープンAPI時代の要だと思い、今回のDroidKaigiのテーマとして取り上げさせて頂きました。

終盤のエモい部分

いくらOAuth2.0やFIDOを実装したところで、リスクから解放されることはありません。それぞれの仕様を安全たらしめているものがいつ危殆するかわからないからです。従って、目を光らせて最新の情報を追わなければなりませんが、既存の仕様を理解しつつ、常に最新を追うのは、これはなかなか骨です。そこで仲間が必要になるわけですが、なかなかセキュリティと開発が交わるチャンスは少ないです。願わくば、本セッションを通じて、すこしでも認証・認可について面白いと感じて頂いて、価値をユーザーに安全に提供するための仲間になっていただければ幸いです。

スタッフとして

相変わらず最高のチームでした。そんなチームですが、一端の中小企業の規模になりつつあり、参加者様も過去最多になりました。そのような状態で、どのように円滑・安全に運営していくかが、今後のワイの仕事になりそうです。 宜しくお願いします。

2017年を雑に振り返って、2018年の目標を雑に立てる

2017年振返り

1月

Android(Java)以外のプログラミングとして、初めてGoを弄り始める。自分ツールとして、GSuiteのコマンドラインツールをGoで作成。Slack Botも作成していたりしました。Reduxを勉強し始めている形跡があるが、正直ここらへんは自分のキャリアや人生に迷ってた間があります。後、副収入を得たのもここらへん。ちなみに、GSuiteツールキットは次のリポジトリ。正直ウンコだと思う。

github.com

2月

ちょびちょび前述のGSuiteのコマンドラインツールを作ってもいたけど、基本的にはDroidKaigiの準備をしていた模様。その過程で、使ってないActivityがあったら検知してくれるLintを作ったりしました。更新できてない... github.com

3月

DroidKaigiで「ドキッ★脆弱性 onCreate() から onDestroy() まで」発表。会社のアプリに脆弱性の報告をされたので、原因や対応フローといったのをコミュニティ内でシェア。Webアプリ(Railsエンジニア）の人と一緒にDockerデビュー。実はこのタイミングで、CISOの椅子を用意してくれていたスタートアップに転職しようとしていた。何やかんやあって、半年待ってもらうことに（結局、今の会社に残ったけど）

ドキッ★脆弱性 onCreate() から onDestroy() まで // Speaker Deck

4月

基本的に会社のことしかしてなかった。死ぬほど忙しかった。会社でWindowsサーバー・ドメコン・グループポリシーの権限部分でｳﾝｳﾝ唸ってた。Twitterのタイムラインみると3am~4amまで仕事してた模様。引くわ〜。社長への報告とかもここから始まったかも。会社の全体的なセキュリティ方針とかお願いする予算とかも弾いてて、結構プレッシャー大きかった。ポッドキャスト「セキュリティのアレ」に準レギュみたいなポジションから参加したのも、ここらへんから。

5月

仕事については、大体４月と同じ。休日はTerraformをちょろっといじったりしてた。また、自分でコマンドラインを作ったりした結果、「もっとちゃんとプログラムの基礎やんないとなー」と思い立ってたのはここらへん。Googleが学生向けの技術開発者キャリアでやっておくべきことをリストしておいたので、そのチェックリストを作る。

github.com

6月

上記のを見て、暗号に関する授業をCourseraで修了。Andrew NG教授のMachine Learningもなんだかんだで終わってなかったの修了。両方ともCertificateは貰った。ただ、暗号の授業は面白かったけど、何となく思ってたのと違った。僕がのぞんでたのは、結城先生の「暗号技術入門」& 実装だったんだけど、Courseraは暗号が安全であるための数学的要件や攻撃方法がメインだった。なので「Javaで作って学ぶ暗号技術 - RSA,AES,SHAの基礎からSSLまで」を参考にして、Goを使った実装をしている。RSAとAESまでできたけど、SHAからSSLまでは出来てない。やるかは...わからない。色々やりたいことがあるので。あと、地味にGCP, コンテナ, k8sを使ったサイトを１つリリースしてた。更新は手動。

github.com

http://amzn.asia/crpzzCh

7月

仕事は相変わらず死んでたけど、技術的なことというより、非技術的な調整をしまくってて忙しかった。エンジニア is 何、セキュリティ is 何と超自問自答してた時期。 前述の暗号 in Goを実装しているときに、Techboosterのmhidakaさんにテクブで声をかけられる（もともとDroidKaigiで知り合いであった）。２つ返事でおｋしたのが運の尽き。 ひーこらいいながら、AndroidのSMS Verifier APIについての初原稿を仕上げる。次のリンクから買えるで。

techbooster.org

あわせて、ssmjpで話してほしいといわれたので、やはり何も考えずに受けて、ひーこらいってた。NISTからDigital Identity Guide (SP800-63)がでたので、そのSMS認証について話す。これを日本語で不特定多数の前で話したのは、僕が初めて...かも...?

俺のSMS認証がこんなに非推奨なわけがない // Speaker Deck

GoogleのSecurity Princessと呼ばれる方が書いたセキュリティを専門にするひとの心得、というのを日本語訳した。これが結構バズった。そしてビビった。

ken5scal.hatenablog.com

8月

仕事は相変わらず（略。で、プログラミングしなさすぎてヤバイな、と思ったので、隙間時間で会社で使ってるサービスのAPIを叩くクライアントアプリを作成。コマンドラインも作っておいた。ビルドは手動でmakeファイルさえ作ってない。地味にAWSを始める（インスタンス立てるだけじゃなく、組織の中でちゃんと使う）。SlackのChat Botもここら辺でデビュー

github.com

9月

ソフトウェア的な活動は特にせず。お仕事は一旦落ち着く。ちょっとダレる。夏休みとしてエストニアに旅行にいく。 e-govショールーム、Funderbeam、Transferwise、Verif、Cybernetica、SK IDソリューション、エストニア情報センター(RIA)に訪問したりしていた。終わった後に、自分が所謂「日本企業の視察・情報収集」しかしてないことに気づき、激しく自己嫌悪。いや、日本のFintech事情とか話したけど、貰った情報の価値からしたらちょっと...。尚、ご飯は口に合わなかった模様。歴史的にはものすごい面白く、なぜエストニアが現在のエストニアになったかが理解できた。そして、その歴史的背景無視して日本が真似してもしゃーないのでは、というスタンスになった。そんな間に会社が上場。

10月

GCP, k8sでのインフラ構築２サイト目を構築開始。技術書典３に「ニッチ・セキュリティ」サークルから「現時点で日本語でググっても出てきにくいセキュリティ技術」を出す。自分はUAF 1.1に書いたが、一緒に参加頂いたbbr_bbqさんと北原さんの記事のクオリティの高さに完全降伏した。幸い好評のうち終了。

techbookfest.org

11月

GCP, k8sでのインフラ構築２サイト目の構築終了。色々あって神経をすり減らす。

12月

上記のサイトでバックエンドサーバーが必要になったので、gRPCデビュー。サーバー側はGoで、クライアント側はRubyで書いた。再度、mhidakaさんに誘われて、テクブ本を書く。今回のテーマはFirebaseを使った認証。何だかんだ言ってKotlinまだ触ってなかったので、全てKotlinで書く。

techbooster.org

ふりかえると

色々やってるな〜（小並 (´ε｀；)ｳｰﾝ…振り返ると殆ど仕事しかしてない気配です。何度か精神やばいな、っておもったことあるんで、ちゃんと休みはとろう。 今年の目標はQoLを上げるのも含めておいたいと思います。

で、これが去年の目標なわけだが、CISSP/機械学習/サービス作成というのができてませんな。 http://ken5scal.hatenablog.com/?page=1483260359

筋トレにあまりいけなくなっている事実は見過ごし難い。

そしてCNCFとの出会いや4月からの仕事で、完全に趣向が変わってきてはいる。

ブロックチェーンの流行りなど、新しい技術を眺めているだけでいいのだろうか。

CISSPとらなかったなあ

2018年の目標

やりたいことは沢山あるが、やはり基礎と認証・認可を固めて行こうと思う。また、攻撃技術は身に着けないとだめそう。コマンドライン自分で作ったけど、テストないと厳しい。QOLをあげるために、規則正しい生活を。

絶対やる

• アルゴリズムとデータ構造
  • 「なっとく！アルゴリズム」
  • 「アルゴリズム　クイックレファレンス」<- 買うだ
• テスト
  • 「テスト駆動開発」
• FIDO UAF1.1
  • docomo Xperia XZ SO-01Jを買わないと...
  • 一応PIXEL2も対応していそう Google Details the Pixel 2's Tamper-Resistant Hardware Security Module
• OAuth2.0/OIDC
  • 「OAuth in Action」の写経
  • RFCを片っ端から読む
• CTF
  • ksnctf, マクニカctf
  • Web Application Penetration Testing Training Course - WAPT - eLearnSecurity
  • GWEB？
• CNCF
  • k8s, notary, utf, spiffe, istio, spinakker
  • AWS, GCPの何らかの資格は取りたい。セキュリティ系で。
• 健康づくり 　 早く寝る。早く起きる。効率的にやるため、昼にyoutube、SNSをぐるぐるみるのやめる...やめたい... 　 朝ジム: いつものメニュー、有酸素運動、体幹作り 　 自分のスケジュールに依存しない形で、健康づくりしたい。 　 瞑想 　* 野菜を食う。夜はなるべく食わない。　
  • 後、山登ります山
• GREを見据えた英語
• Discrete Mathematics, Computer Systems

時間があったら

• サービス作り。「Go Web Programming」
• CISSP, CISA?
• 「Real HTTP World」
• 機械学習 -> 原点に立ち返って考えると、わいは異常検知をやりたかっただけなんや...個人的に数冊本読んで、kaggleに手をだす？
• ブロックチェーン -> とりあえずフォロワーレベルでいいかな。本職はセキュリティで、いまだユースケースの確定してないところに本腰いれてつっこんでも迷子になるだけそう。入門書を数冊読んで、下を真似するぐらいで、今はいいかも。 Building Blockchain in Go. Part 1: Basic Prototype · Going the distance

Androidアドベンドカレンダー、Firebase Authenticationで電話認証する #Android #Authentication

Android アドベントカレンダー 20日目の記事です。

qiita.com

とある同人誌に掲載する予定だったのですが、風邪でぶっ倒れて書けなかった最終章をこちらに書きます。 内容は、Firebase Authenticationを使った電話認証のあれこれです。以降、「Firebase Authenticationの電話認証」を電話認証として略させて頂きます。 また、本稿ではFirebaseの仕組み上、みんなだいすき2要素認証ではなく2段階認証と呼称させていただきます。 詳しくはこちらをご覧ください。

blogs.manageengine.jp

本稿は次の内容でお送りします。 - ベーシックな電話認証 - 既存アカウントとのヒモ付け - 電話認証を使ったなんちゃって2段階認証 - SMS Retriever APIを使った半自動2段階認証

では、やってまいりましょう。

ベーシックな電話認証

いきなりで申し訳ないのですが、電話認証を実装したアプリはエミュレータ上では実行できません。いや、実行はできますが、電話認証周りの機能は動きません。クラッシュとかではなく単純に動きません。実機をご用意ください。

まずは電話番号をFirebaseに登録する必要があります。その場合、1) その電話番号が本当に実在するものか、2) 登録要求をリクエストしたユーザーのものであるか確認をとる必要があります。コードでお話すると、まず PhoneAuthProvider.getInstance().verifyPhoneNumber で電話番号の存在を確認し、そして、その後SMS経由で送られた確認コードをユーザーから受理・検証することで、登録要求リクエストの真正性を確認します。

1) はFirebaseの PhoneAuthProcider.getInstance().verifyPhoneNumber を使って出来ます。

　　 // 該当の電話番号に確認コードを送った結果を受け取るコールバック
        mCallbacks = object : PhoneAuthProvider.OnVerificationStateChangedCallbacks() {
            // 後でつかいます
            override fun onVerificationCompleted(p0: PhoneAuthCredential?) {
                Toast.makeText(this@EmailPasswordActivity, ": Verification Completed", Toast.LENGTH_SHORT).show()
            }

            // 後でつかいます
            override fun onVerificationFailed(p0: FirebaseException?) {
                Toast.makeText(this@EmailPasswordActivity, p0?.message, Toast.LENGTH_SHORT).show()
            }

            override fun onCodeSent(p0: String?, p1: PhoneAuthProvider.ForceResendingToken?) {
                mSMSVerificationID = p0.toString()
            }

            override fun onCodeAutoRetrievalTimeOut(p0: String?) {
                mSMSVerificationID = p0.toString()
            }
        }


    private fun registerPhoneNumber(phoneNumber: String) {
        PhoneAuthProvider.getInstance().verifyPhoneNumber(
                phoneNumber, // E.164フォーマットである必要があります。このフォーマットは[+][国コード][エリアコード]になります。例えば080-1234-5678が電話番号なら、E.164フォーマットで+818012345678です。
                10, // 10秒でタイムアウトする
                TimeUnit.SECONDS,
                this@EmailPasswordActivity,
                mCallbacks
        )
    }

2) は真正性確認になります。ユーザーが取得した確認コードとmCallback内で取得したSMS確認IDを組合せてたクレデンシャルがまずは作成されます。アプリはそれをサーバーに送信し、サーバーはそれを検証します。

val auth = FirebaseAuth.getInstance()
val credential = PhoneAuthProvider.getCredential(mSMSVerificationID, verificationCode)
auth.signInWithCredential(credential).addOnCompleteListener { task ->
    if (task.isSuccessful) {
        auth.currentUser?.let { updateResult(it) }
    } else {
        Log.w("Phone", "signInWithPhoneAuthCredential:failure", task.exception)
        Toast.makeText(this, "Authentication failed.", Toast.LENGTH_SHORT).show()
    }
}

タスクが成功した場合、その時点で電話認証をしたユーザーはFirebaseに登録されていることになります。次の画像をご参照ください。

とてもハンディですね。

既存アカウントとのヒモ付け

でも、これでは既存アカウントに紐付いてません。単純に、新しい別のアカウントが生成されただけです。既存アカウントに紐付かせるために、電話認証で登録したアカウントを削除したうえで紐付かせたいアカウントにリンクさせてみましょう。下記の様にログイン済みのユーザーにクレデンシャル(SMS確認IDとSMSに送られた確認コード）をリンクさせればおｋです実装すればおｋです。

val auth = FirebaseAuth.getInstance()
val smsCredential = PhoneAuthProvider.getCredential(mSMSVerificationID, findViewById<TextView>(R.id.mfa_code).text.toString())
auth.currentUser?.linkWithCredential(smsCredential)?.addOnCompleteListener { task ->　// auth.currentUserはFirebase Authenticationですでにサインインしているホスト
     if (task.isSuccessful) {
          mAuth.currentUser?.let { updateResult(it) }
     } else {
          Toast.makeText(this, task.exception?.message, Toast.LENGTH_LONG).show()
     }
}

ひも付きました。

次は２段階認証の話になります。

電話認証を使ったなんちゃって2段階認証

上記の通り、複数の認証プロバイダ（メールアドレス、電話番号）を１つのアカウントに紐付けることができました。そこでメアドとSMSを使った２段階認証を設定してみたいと思います。 注意: 今のFirebaseの仕組み上、メアド・パスワードの認証が成功した時点でサインインした状態になってしまいます。従って、一度サインアウトして更に電話認証する流れになります。なので、本章はなんちゃってとなっています。

流れとしては、signInWithEmailAndPasswordでサインインしたユーザーの情報から電話番号を取得し、確認コードを送ります。これはFirebaseのContinuationインターフェースを使って実現できます。ContinuationインターフェースではTaskの結果を受取り、任意の処理を実行・出力する実装ができます。

// 認証結果を元に、電話番号へ確認コードを送る
class Send2FAVerificationCodeToSMS(
        private val executor: Executor,
        private val callback: PhoneAuthProvider.OnVerificationStateChangedCallbacks) : Continuation<AuthResult, Unit> {
    　override fun then(task: Task<AuthResult>) {
        　if (!task.isSuccessful || task.result.user.phoneNumber.isNullOrEmpty()) {
            　return
        　}
        　return PhoneAuthProvider.getInstance().verifyPhoneNumber(
                task.result.user.phoneNumber.toString(), // Needs to be E.164 format. eg. +81805541xxxx(Japan), [+][country code][subscribed number with area code]
                10,
                TimeUnit.SECONDS,
                executor,
                callback
        )
    }
}

// 何となく別スレッドで処理したかった
class ThreadPerTaskExecutor : Executor {
    override fun execute(r: Runnable) {
        Thread(r).start()
    }
}

// 上記をsignInWithEmailAndPasswordのタスク終了後に実行する
mAuth.signInWithEmailAndPassword(email, password)                    
                .continueWith(Send2FAVerificationCodeToSMS(ThreadPerTaskExecutor(), mCallbacks))
                .addOnCompleteListener { task ->
                    signOut() //signInWithEmailAndPasswordが成功した時点で、サインイン済みになってしまっているのでサインアウトを実施
                    if (!task.isSuccessful) {
                        Toast.makeText(this, task.exception?.message, Toast.LENGTH_LONG).show()
                        return@addOnCompleteListener
                    } else {
                        Toast.makeText(this, "Verification Code has been sent", Toast.LENGTH_LONG).show() 
                    }
                }

手元の携帯電話に確認コードが送られてきました。前章で紹介したとおり、このコードと確認IDを組合せたクレデンシャルを引数にするsignInWithCredential を呼び出せば、メールアドレス認証と電話認証を組合せた２段階認証の出来上がりです。

SMS Retriever APIを使った半自動2SV認証

ところで皆さん、2SVするとき電話番号入力するのめんどくさくありませんか？次のような手順を見て頂ければ、半分くらいのかたには同意頂けるかと思います。

1. 自分の電話番号を入力
2. サーバからの認証コードを待つ
3. SMSまたは電話アプリを立ち上げる
4. 認証コードを入力

このステップ2からステップ4までを自動化してくれる仕組み、それがGoogleがだしているSMS Retriever APIです。 当該APIを使うことで、サーバからSMSを受け取ったAndroid端末（のGoogle Play Service）がブロードキャストし、特定のアプリがそれを受信・SMSをパースできるようになります。 パースさえできれば、その後処理でサーバに認証コードを送るだけなので、ユーザー体験を損なわない自動的な2段階認証を提供できるわけです。

以下、実装を軽くみていきます。 注意: なお、筆者はスマホ（SIM Free機）と電話を分けて運用しているので、本章は動作確認できていません。

SMS Retriever APIの呼び出し

SmsRetrieverClient インスタンスを生成し、startSmsRetriever()を呼びます 立ち上がったAPIもといタスクは認証コードを含んだSMSが届くのを待ちます。5分立つとタイムアウトしますが、待ち時間は変更できます。

class PhoneNumberVerifier : Service() {

    private var smsRetrieverClient: SmsRetrieverClient? = null

    override fun onCreate() {
        smsRetrieverClient = SmsRetriever.getClient(this)
    }

    // このサービスは `PhoneAuthProvider.getInstance().verifyPhoneNumber` の実行直後に呼び出される
    override fun onStartCommand(intent: Intent, flags: Int, startId: Int): Int {
        super.onStartCommand(intent, flags, startId)

        val action = intent.action
        if (ACTION_VERIFY == action) {
            val task = smsRetrieverClient!!.startSmsRetriever()
            task.addOnCompleteListener {task ->
                if (task.isSuccessful) {
                     // 何か. smsRetriever開始成功のお知らせ
                } else {
                     // 何か. smsRetriever開始失敗
                }
            }
}

SMSから認証コードの取り出し

認証コードが端末に届いた際、Google Playサービスが、SmsRetriever.SMS_RETRIEVED_ACTIONを指定した明示的なブロードキャストを発信します。このブロードキャスト内に認証メッセージが届くわけです。従って、アプリ内ではBroadcastReceiverで本メッセージを抽出します。

class SmsBrReceiver : BroadcastReceiver() {

        override fun onReceive(context: Context, intent: Intent?) {
            if (intent == null) {
                return
            }

            if (SmsRetriever.SMS_RETRIEVED_ACTION == intent.action) {
                val extras = intent.extras
                val status = extras!!.get(SmsRetriever.EXTRA_STATUS) as Status
                when (status.statusCode) {
                    CommonStatusCodes.SUCCESS -> {
                        val smsMessage = extras.get(SmsRetriever.EXTRA_SMS_MESSAGE) as String
                        Log.d(TAG, "Retrieved sms code: " + smsMessage)
                    }
                    CommonStatusCodes.TIMEOUT -> doTimeout()
                    else -> {
                    }
                }
            }
        }
}

ここで取得したsmsMessage = 確認コードを、前述のsignInWithCredentialにいれてFirebaseに送信することで、半自動2SVが完了します。

//mSMSVerificationIDはPhoneAuthProvider.OnVerificationStateChangedCallbacks()のonCodeSentから取得
val credential = PhoneAuthProvider.getCredential(mSMSVerificationID, code) 
mAuth.signInWithCredential(credential)

以上です。

終わりに

以上で、Firebase Authenticationの電話認証周りの紹介をさせていただきました。認証システムは設定するには非常に多くの考慮が必要ですので、Firebase Authenticationを利用すれば、ベストではないにせよ２段階認証までハンディに実装できるようになります。

High Sierraのパスワードレスrootログインの注意点と対策方法

japanese.engadget.com

話題になってるので、改めて説明をする必要はないと思うので、注意点・対策方法について記載しておく。

注意点

どこかの記事の対策として"root"を無効化する、とあった。でも、rootと打ち込むと勝手に有効化されるので意味がありません。パスワードを変更してから、無効化してください。

パスワード変更

ローカル管理者権限を持ってる場合

下記のうちいずれか

• CLIベース % sudo passwd root

• GUIベース

• システム環境設定 > ユーザーとグループ > ログインオプション > 編集

• ディレクトリユーティリティを開く > 編集 > ルートパスワードを変更

↑のいずれの方法でも対策できるのは確認済み

組織内の端末管理者向け

組織の管理者だったら、Mac管理ツールで下記のスクリプトを配布すればいいと思います。こちらも大丈夫そう。検証してから使ってね。

Blocking logins to the root account on macOS High Sierra | Der Flounder

余談

報告者のtweetを見にいったところ、公開方式について ちゃんとDisclosure Policyに従って報告しろよ派 vs Appleが悪いのに何がダメなんだ。それを気にするのは報告者の責任ではない派 の論争が繰り広げられてて面白かった　（コナミ。

GCPのIdentity-Aware Proxyためしてみた #GCP #IAP

GCPで動かしてるWebサービスのstg環境にIdentity-Aware Proxy(IAP)噛ませてみた。これにより外部からアクセスする際、ドメインのサイトにたどり着く前にGoogleアカウントの認証が必要になった。事前に許可されたGoogleアカウントでなければサイトにたどり着くことすらできなくなる。つまり、アカウントとクレデンシャルが正しかろうと、IAPに登録されてなければ、アクセス権限が一切ない状態になる。

設定方法は簡単で、「IAM & Admin」 > 「Identity-Aware Proxy」で対象のリソースでIAPを有効化させるだけ！簡単。

なお、Firewallでガバガバに設定していたりするとIAPをバイパス出来てしまう。その場合、warningサインがでていることになるらしい。僕の場合は、大体プロジェクト作成時にdefault firewall ruleを消してしまうので、そういうことはなかった。

*　元サイト

• IAPをかませると誘導される画面

• 失敗画面（実在するアカウントでためした）

こいつのイカス所は、アクセス権限対象を細かく切れるところだと思う。 Googleアカウントはもちろんのこと、サービスアカウント、Googleグループメール、ドメイン全体など様々なスコープに対応している。例えば、外部協力会社さんが既に保持してるGoogleアカウントをそのまま使えることができる（GSuiteに新規登録して月額支払わなくていい）

以上。

DockerfileのADD/COPYに--chownオプションができた

• 11/10: 追記。CI/CDでの制限について書いてなかった。

Dockerのベストプラクティスに、サービスをnon-rootユーザーで走らせなさい、というのがある。

docs.docker.com

そうすること自体は簡単なのだけれども、当然ながらユーザー権限にあわせてコンテナ内のファイル等の権限を設定しなきゃいけない。仮にUSER指定した後にCOPYしてもroot:rootの権限になるので、別途chownをしてやらなければならなかった。

USER app
COPY . $APP_DIR  # $APP_DIRの権限はroot:root
RUN chown -R app:app $APP_DIR

RAILSなど関連ファイル数が結構な量になるサービスの場合、すべての権限が変わるまで10min~15minとか余裕でかかってた。このせいで、dockerのベスプラに従ってなかった人は多いと思う。僕も無視してた（ごめん）

それがv17.09.0-ceから解決された。

Release v17.09.0-ce · docker/docker-ce · GitHub

まあ、端的にいうと ADD/COPY に chown をオプションでつけられるようになったのだ。

USER app
COPY --chown=app:app . $APP_DIR

当然ビルド時間も気にならないぐらい短いので、是非dockerのベスプラに従っていこう。

追記

尚、CI/CDのDockerのバージョンがv17.09.0-ceでなければ意味がない。例えばGCPのContainer Builderはv17.06ぐらいなのでビルドに失敗する。考えてみれば当たり前である...

SMSによる2要素認証は本当に非推奨なのか？

きっかけ

ssmjpで発表してきました。最近、「NISTはSMSによる2段階認証を非推奨」という記事をよく見るようになりました。でも、それって昨年度のPreview版の話で、2017年7月のPublic版でもそうなの？という疑問がわいたので、根性だしてNIST SP800-63bを読んできました。

結論

Public版では非推奨ではありません。CISTによる指摘を、NISTが受け入れたようです。ただ、非推奨をそのまま取り下げたのではなく、SMSを超えて公衆交換電話網(PSTN)経路のOut-of-Band認証にスコープを広げ、「コレを使うならあれせいこれせい」といった諸条件を追加しています。このために、RESTRICTEDな認証と分類されています。ちなみに他の認証方式にRESTRICTEDに分類されたものはありません。

課せられた条件とは。

ちなみに諸条件は、下記の通りです。

• RESTRICTED以外の認証方式を1つ以上提供しなければならない
• RESTRICTED認証方式のリスクアセスメントをしなければならない
• リスクアセスメントの結果を利用者にわかりやすい形で届けなければならない
• RESTRICTED認証方式が禁止されたときに備えた移行プランを準備しなければならない

B2BならいざしらずB2Cなサービスに2段階認証を整備するとなると、PSTN経路のOut-of-Band認証方式はほぼ避けられないですね。厳しいです。ちなみに日本においてPSTN経路は廃止される予定ですが、総務省の計画では2025年です。それまで2FAを準備しないのは、まあ、ないでしょうね...　米国でのサービス展開を考えているなら、今から対応しておいたほうがよさそうです。

ただ、アメリカみたいにグローバルなIT企業がばっこしているところだろ、本国のPSTNは安全でも、途上国のは脆弱な経路になるんだろうなぁ...とも思っています。

余談

NISTのパブコメはGithubで公開されています。本件のissueは下記をご参照ください。

github.com

色々差を感じるなぁ...エクセルやめようぜ...