Got Some \W+ech?

Could be Japanese. Could be English. Android, セキュリティ, 機械学習などをメインに、たまにポエムったり雑感記載したりします。

Frontend/BackendのOAuth2.0クライアント書いてみた

個人的に認証・認可まわりに興味を持ち出して以来、RFCやドキュメントを読みまくっていた。しかしながら、仕事が忙しかったり、そもそもここらへんを仕事でやるポジションにいないため、ちゃんと実装してみないことにはどうにもならんな、と思いだした。よって、最終的なゴールを雑なFAPI*1準拠したOAuth/OIDCシステムを実装していくことにした。具体的には以下の順番でやろうとしている。認証はもしかしたら、以前つくったFIDO2サーバー使うかも。

  • OAuth2.0クライアント(Code Grantのみ)
  • OAuth2.0認可サーバー
  • OAuth2.0リソースサーバー
  • FAPI Part1化
  • OIDC化
  • FAPI Part2化

まずは、OAuth2.0クライアントを雑に作成した。ある程度できたので、一旦、棚卸しもかねてブログを書く。 その過程で湧いた疑問は、解を求める終わりのないRFC・ドキュメント漁りの旅にでるよりも、所感をこの場に残して、棚にあげようと思う。

構成

Front: Vue。Authorization Requestを送信する。

GitHub - ken5scal/oauth-client-front

Back: Go。Token Requestを送信する。

GitHub - ken5scal/oauth-client-back

AS: Okta Preview。rfc6749に則ってて扱いやすかった。 RS: なし

f:id:kengoscal:20190607015111p:plain

なぜ、フロントエンドとバックエンドを分けたのかと言うと、

  1. FAPI R&Wが認可レスポンスのパラメタインジェクション攻撃やIdP Mix Up攻撃への緩和策として、OIDC Hybrid Flowを必用としているから
  2. 過去いた会社では、どのようなステージだろうがビジロジック部(バックエンド)とUI部(フロントエンド)を担当するチームが別だったから

といったところから、分割している。

実装(一部)

  • Authorization Requestを送るVue Component(/pages/index.vue)
<template>
<v-btn color="info" @click="requestForAuthorizationCode">Authorize</v-btn>
</template>

<script>
export default {
data() {
    return {
      unreserverdChars: //★PKCEで使うChar郡。RFC3986 Sec2.3参照
        '0123456789ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz-._~'
    }
  },
mounted() {
    // because it's in dev, secure attribute is set as false
    const state = uuid() ★stateとして作成。本当はRedisに保存したい。
    Cookie.set('SessionID', state, {
      secure: process.env.NODE_ENV !== 'development'  
    })
  },
methods: {
    // https://tools.ietf.org/html/rfc7636
    requestForAuthorizationCode() {
      let codeVerifier = ''

      const l = this.unreserverdChars.length
      for (let i = 0; i < 128; i++) { //★PKCEのCode Verifierは48~128長だが、長くてなんの問題があるんじゃい、と128固定
        codeVerifier += this.unreserverdChars[Math.floor(Math.random() * l)]
      }
      this.$store.commit('oauth/setVerifier', codeVerifier) ★後につかうのでVuex保存。保存先はSession Storage。

      window.crypto.subtle
        .digest('SHA-256', new TextEncoder().encode(codeVerifier)) ★Code Challenge生成。Plain使ったらPKCEの意味ないよね...なくない...?Sha256できない環境が想像できない。
        .then(digestValue => {
          const codeChallenge = window
            .btoa(
              new Uint8Array(digestValue).reduce(
                (s, b) => s + String.fromCharCode(b),
                ''
              )
            )
            // base64 to base64url
            .replace(/\+/g, '-')
            .replace(/\//g, '_')
            .replace(/=/g, '')

   // ★Authorization Request
          window.location.href =
            process.env.oktaAuthzEndpoint +
            '?client_id=' +
            process.env.oktaClientId +
            '&response_type=code&scope=openid offline_access' +
            '&redirect_uri=' +
            process.env.oktaAuthzRedirectURL +
            '&state=' +
            Cookie.get('SessionID') +
            '&code_challenge_method=' +
            'S256' + // For Now
            '&code_challenge=' +
            codeChallenge
        })
        .catch(err => {
          // console.log(err)
        })
    }
  }
</script>
  • 認可サーバーから認可コードを送り、それをバックエンドに連携するVue Component(/pages/callback.vue)
<script>
import axios from 'axios'

const Cookie = process.client ? require('js-cookie') : undefined

export default {
  mounted: function() {
{
    // Checking CSRF attack on the `code` during the Authorization Response
    if (this.$route.query.state !== Cookie.get('SessionID')) { ★認可コード差し込み対策
      this.$root.error({
        statusCode: 403,
        message: 'State is invalid. Suspected to be CSRFed.'
      })
    } else {
      this.authzResponse = this.$route.query
      axios
        .post(
          'http://localhost:9000/token', ★
          JSON.stringify({
            authz_code: this.$route.query.code,
            code_verifier: hoge // this.$store.getters['oauth/getVerifier']★PKCE: 認可コード横取り対策
          }),
          {
            headers: {
              'Content-Type': 'application/json'
            }
          }
        )
        .then(res => {
          this.tokenResponse = res.data
        })
        .catch(err => {
          this.tokenResponseError = err.response.data
        })
      this.$store.commit('oauth/removeVerifier')
    }
  }
}
</script>
  • Token Requestを送るGoバックエンド。この後、microservice的なデプロイも試してみたいので別リポジトリに分割。
func init() {
    tomlInBytes, err := ioutil.ReadFile("config.toml")
    if err != nil {
        log.Fatal().AnErr("Failed reading config file", err)
    }

    config, err := toml.LoadBytes(tomlInBytes)
    if err != nil {
        log.Fatal().AnErr("Failed parsing toml file", err)
    }

    // Maybe server config
    port = strconv.FormatInt(config.Get("env.dev.port").(int64), 10)

    oauthConfig = oauth2.Config{
        ClientID: config.Get("env.dev.as.okta.client_id").(string),
        ClientSecret: os.Getenv("CLIENT_SECRET"),
        RedirectURL: config.Get("env.dev.as.okta.callback").(string),
        Endpoint: oauth2.Endpoint {TokenURL: config.Get("env.dev.as.okta.token_endpoint").(string)},
    } //ConfigFromJSONの ConfigFromJSONが参考になる
}

func handleTokenRequest(w http.ResponseWriter, r *http.Request) {
    defer r.Body.Close()
    var b struct {
        AuthzCode string `json:"authz_code"`
        CodeVerifier string `json:"code_verifier"`
    }

    if err := json.NewDecoder(r.Body).Decode(&b); err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        fmt.Fprintln(w, err.Error()) ★
        return
    }

    opt := oauth2.SetAuthURLParam("code_verifier", b.CodeVerifier)★PKCEのパラメタはOption指定すればおk
    token, err := oauthConfig.Exchange(context.Background(), b.AuthzCode, opt) ★OAuth2パッケージ便利
    if err != nil {
        w.WriteHeader(http.StatusBadRequest) 
        fmt.Fprintln(w, err) ★本当はrfc6749 sec5.2の通りパースしたかったが無理そう。だってこれだし↓。PRが出てるのは確認ずみ
                 //oauth2: cannot fetch token: 401 Unauthorized
        //Response: {"error":"invalid_client","error_description":"Client authentication failed. Either the client or the client credentials are invalid."}
        return
    }

    tokenForFront := &struct {
        AccessToken  string    `json:"access_token"`
        TokenType    string    `json:"token_type"`
        RefreshToken string    `json:"refresh_token,omitempty"`
        Expiry       time.Time `json:"expiry"`
    }{
        AccessToken: token.AccessToken,
        TokenType: token.TokenType,
        Expiry: token.Expiry,
    }

    w.Header().Set("Content-Type", "application/json;charset=UTF-8")
    w.Header().Set("Cache-Control", "no-store")
    w.Header().Set("Pragma", "no-cache")
    w.WriteHeader(http.StatusOK)
    json.NewEncoder(w).Encode(tokenForFront)
}

メモ・疑問・所感

response_type の話

最新ドラフトの「OAuth2.0 Security Best Current Practice」*2によると、クライアントはImplicitグラントタイプや"token id_token"および"code token id_token"といった認可レスポンス内にアクセストークンを入れるものを実装すべきでないと書いてある。このベストプラクティスに従うと、FrontendとBackendで分けたHybrid Flow構成の場合*3、"code id_token"くらいしかオプションが残らない。まあ、それは構わないのだが、もし"code id_token"を使うのであれば、Backend側にしかアクセストークンが保持されないため、Implicit GrantなどによるFrontend上で起きやすかったアクセストークンの漏洩について気にするポイントは減らすことができる。その場合、アクセストークンを sender-constrained するMTLSやToken Bindingが果たしてFAPIのRead & Write Profileでも必要なのだろうか?という疑問はある。それを踏まえたうえで必要なのかもしれない。よくわからん。気にするより、実装を進めることにした。

PKCE の話

「OAuth2.0 Security Best Current Practice」ではImplicit Grantを使うべきではない(Should Not)と書いてあるので、基本はCode Grantになる。その場合、PKCEが必須になる*4ため、実装した。ネイティブアプリではカスタムスキーマによって認可コード横取りされる経路が明示的にあるもののhttpsスキーマ使うクライアントアプリなら大丈夫じゃない??とも思ったが、PKCEは実装も管理も比較的ライト(だと思う)なので、特に違和感はなかった。

あと、code_verifierってどこに保存するのがベストなんだろう。クッキーにいれるのもちゃうし、ローカルストレージはWindow閉じても消えないし...で、ライフサイクルとしては短い(と思う)ため、XSSなどによる攻撃を受けるリスクは少ないということから、一旦 Session Storageに格納。

セッションとトークンの話

ネット上でJWTをセッション管理にすればいいじゃん!いやだめだ!という議論をよく見るが、そもそもJWT*5ってクレームのフォーマットであり、どうも議論自体の論点がよくわからん...という気持ちが強かった。今でもよくわかってないのが正直なところだが...で、いざOAuth2.0クライアントを実装してみると、別物という結論に自分の中で達し、Cookieを使う方針にした。ID Tokenを取得して検証が成功したら、クッキーを足せばいいんじゃないだろうか。

golang/oauth2/について

便利。最初はクライアントもスクラッチで書いちゃろ!と思ってたが、Exchangeの中身が素直だったのと、ASをOktaだけ使う場合は単純なhttp requestにしかならないので辞めた。個人的にはToken RequestのエラーがError型で帰ってくるのは辛かった。パースしてえ。まあ、ASによって仕様が違うからしょうがない。ただ、それに関するPRが4月に作成されているが反応がない。ほかのissue/prへの反応が2019年にはいってから低速化してるように見えるが、気のせいだろうか。あと、ASによって異なる仕様を拾うための仕組みが参考になった。ただし、全体的な設計は知識不足からかよくわからない。なぜ、ここにInterfaceを配置したのか、なぜモジュールを分けたのかなど....

github.com

フロント

フロント何もわからん。技術書典で、SPA構成を使ったWebアプリの本をパクり、Nuxtでやってみた。 お守りに猫本も脇において読んだが、完全にFront初心者の自分には無理で、猫本どころか公式docもさっぱりだった。 次の本でことなきをえた。公式docも「あーあれね、知ってる知ってる(汗」というところまでは理解できるようになった。

いちばんやさしい Vue.js 入門教室

いちばんやさしい Vue.js 入門教室

ところで現時点だと、フロントにもClient IDをもたせているが、これはフロントの起動のタイミングでバックエンドに取得させにいったほうがいいと思う。が、コンテナオーケストレーションしないとハードル高そうなので、後回し。

インフラ的な構成

RedisとかDBをたててセッション情報やトークンの管理をしたり、Docker-Composeでデプロイしようと思ったが、後回し。 とりあえず、OAuth/OIDCをやりきるのを優先する。

アプリケーションの適切な設計・コード

弱い。エラーハンドリング、テスト等...

フロントサーバーとバックエンドサーバーの認証・認可

認証はx509でSPIFFEEを使うつもり。認可だが、Microservice in OAuthのイメージがわからない。European Identity Conferenceで「ユーザーが使うOAuthとMicroservice間で使うOAuthの違いはなんだ」と聞いたところ、「そこに違いはない」と言われた。ずっと考えていたが、やはり意味がわからない。この答えは10月のIIWで求める必用がありそうだ。

次は

認可サーバー作成する

GCP Next 2019で発表されたセキュリティ機能をAWSのそれとマッピングする

cloud.google.com

Twitterでは収まりきらなそうなので、手を動かすとき用のメモを残しておきます。 カテゴリはしてるけどMECEさは気にしてません

Access Transparency

IaaSプロバイダーによるアクセス履歴のトラッキング。この度、Approvalがでることで承認制にすることもできるようになった。

  • GCP: Access Transparency, Access Approval
  • AWS: NA (CloudTrailじゃないよなぁ...)

DLP

Data Loss Prevention。AWS Macieはまだ東京regionにはまだきてないハズ

  • GCP:
    • VPC Service Control: GCS/BigQueryのデータをVPC内に留めるデータにおける境界予防(Prevention)  * DLP User Interface
  • AWS: Macie

SOC

GCPは基本Cloud Security Command Centerに集約

Prevention

  • GCP
    • Security Health Analytics
    • Cloud Security Scanner: XSSのようなアプリレイヤーにおける脆弱性スキャナー
  • AWS
    • AWS Config
    • AWS Control Tower
    • ※Cloud Security Scanner相当はない(ハズ)

Detection/Response

  • GCP
    • Event Threat Detection
  • AWS
    • GuardDuty

IR Orchestration

  • GCP: Stackdriver Incident Response and Management
  • AWS: Security Hub

API Security

クラウドネイティブセキュリティ (コンテナセキュリティ)

クラウドネイティブセキュリティは @ken5scal が勝手に読んでるだけ。冒頭に紹介したブログだとSupply Chainと書かれていたが、個人的に本質はアプリをコンテナでデプロイする際のライフサイクル全体におけるセキュリティだと思っている。 ので、次の記事から用語を参照してマッピングした

www.cncf.io

コンテナレジストリのセキュリティ

Deployment (deploy-time security Control)

  • GCP: Binary Authorization
  • AWS: NA

ランタイムセキュリティ

  • GCP: GKE Sandbox (gVisorベース)
  • AWS: NA

コンテナホストのセキュリティ(Runtime Environment Hardening?)

CIAM (Customer IAM)

  • GCP: Identity Platform (Firebase Authenticationとは統合しなさそう)
  • AWS: NA (Cognito?)

技術書典に「Secure旅団」として出してきた話

TL;DR

  • 技術書典6に新刊「セキュリティ畑でつかまえて」を頒布してきました。
  • 新しい試みとして「学生・新社会人応援キャンペーン」を実施しました。
  • 当日いらして頂いた・ご購入いただいた方・執筆いただいた方、本当にありがとうございました
  • 被チェック数は504でした。
  • うち学生・新社会人(2年目まで)は70人ほどでした。
  • 今回は11人で執筆しました。
  • 次の技術書典、当サークルでかいてみませんか?

f:id:kengoscal:20190416024104j:plain

出店してきました

技術書典3から勢いで始めた「Secure旅団」ですが、なんと技術書典6まで続いています。これには飽き性の自分自身驚くばかりです。 まあ、飽き性なところは正直変わってないのですが、「著者の好きなことを書きまくろう」という自分のアウトプット本位から、「多様なセキュリティのコンテンツを届けることで、こういったセキュリティもあるのか、という新しい発見を読者にもたらし、結果的にセキュリティの裾野が広がればいいな」と考えるようになるなど、多少の変化はあったようです。

そんなやつが主宰してるSecure旅団は、今回、様々なセキュリティのコンテンツをギュッと詰め込んだ薄い電子本*1「セキュリティ畑でつかまえて」を技術書典6で頒布させていただきました。

techbookfest.org

以下、目次と著者になります。

  • GATTrackerとBurp SuiteではじめるBLE通信のキャプチャと改変 by @mahoyaya
  • Fridaを用いたWindowsバイナリ動的解析の基礎 by @gr4vit0n
  • Open Policy Agent 入門 by @ken5scal
  • 実践 顔認証システム by @bbr_bbq
  • ポートスキャン入門 by @ozuma5119
  • nmapを使わない邪道なポートスキャン by @tigerszk
  • K Frameworkを用いた脆弱性検出支援 by @K_atc
  • WebAuthnライブラリを組み込んだパスワードレスログイン by @kg0r0
  • コピペで動かすWordPress + WebAuthn by @ym405nm
  • 見習いフォレンジッカー日記 by @greenshallot
  • Terraformで作るHardening的演習環境 by @delphinz

↑に紹介させて頂いた皆様の力なしではSecure旅団は成り立ちません。 略式で恐縮ですが、この場をかりてお礼申し上げます*2

結果

上記の方々の協力もあり、今回はSecure旅団としては最大の頒布数になりました。 総売上はインターネッツ上で申し上げたくないマンなのでいいません*3*4。リアルで会う方にはポロッとお伝えするかもしれませんが...

個人的に一番嬉しい結果だったのは、計70人の学生・新社会人にご購入いただけたことです。

今回は新しい試みとして、学生・新社会人の方には新刊を500円で提供させていただきました。 その背景としては「セキュリティうん十万人不足」*5にあります。 数字の妥当性は置いといて、セキュリティ人材のニーズが高くなりつつある(と見える)のは間違いないです。しかし、どんな人材が不足していて、つまりどの分野に人が足りてないんでしたっけ?そもそもどんなセキュリティ分野と業務がこの日本国にあるんでしたっけ?というのは、セキュリティを主務にしてきた期間が短い方ほど分かりにくいんじゃないかな、と思っています。

だからこそ、多様で優秀な"セキュリティ人材"が寄稿する当サークルのコンテンツから、様々な分野を知り、それをもとに(おこがましいですが)自分の好きな分野へのキャリアを形成できるような層を増やしたい、そのためのハードルを下げたいという意図から、「学生・新社会人応援キャンペーン」を実施しました。 そのキャンペーンに賛同(?)してくれた方が70人もいたので、ああ、やってよかったな、と密かに思いました。

今後

飽き性なので、本サークルがいつまで継続するかわかりませんが、もうちょっと頑張って見たいと思っています。最終的に自分が目指したいのは、セキュリティ人材の不足分を埋めるというより、組織における各チームがセキュリティ機能を持つところにあります。これをどう達成していくかは、結構な頭の悩みどころです。

あと、ちょっと人数も増えてきたので、金回りなど組織的なあれそれをしないといけないので、仲間を募集しています。特に金回りに強いひと...

とりあえず

当日、当サークルに来れなかった方のために、boothでの販売を開始しました。もしよければご覧ください。 secure-brigade.booth.pm

また、もし本ブログを読んで趣旨に賛同いただけたり、新しくセキュリティネタでアウトプットしたい方がいれば、是非、次回の執筆陣にご参加いただければ幸いです*6

*1:なお233ページ

*2:Secure旅団立ち上げのときから、寄稿いただいてる @bbr_bbqさんと@gr4vit0nさんには特にお礼申し上げます

*3:執筆者の皆様には伝えています

*4:言いたい人をsageる意味ではなく、俺はこうしたいというだけです

*5:http://www.soumu.go.jp/main_content/000591470.pdf

*6:その際はDMでもなんでもください

「セキュア旅団」は技術書典6に出店します

TLDL

  • 技術書典6にセキュア旅団として出典します
  • 場所は「え01」です
  • 著者は第一線で活躍している方がそれぞれ自信が注目・取り組んでいるセキュリティのことを好きに書きます
  • すでに10人弱いますが、引き続き著者を募集中です。

f:id:kengoscal:20190227134021p:plain
え01

主題

当サークルの目的

私が参加している「セキュア旅団」の技術書典6当確が決まりました。当日は「え01」にいますので是非起こしください。 思い出せば技術書展3に参加してから早3年なので、改めて当サークルが扱う内容について紹介します。

当サークルは名前の通り、セキュリティをメインに扱うサークルです。しかし、それを1つのトピックに限定することはしておりません。それは、主軸が異なる方にもセキュリティの多様性と楽しさを知っていただきたく事が目的だからです。

これは、NSCが開催しているサイバーセキュリティ月間が謳っている「みんなでしっかりサイバーセキュリティ」*1にも近いのですが、当サークルはよりグロースマインドセットな方向性を攻めて見たいと思っています。

どういうことかというと、当サークルにご参加いただいている著者に「自分(著者)の好きな・夢中になれる・楽しいと思えるトピック」を自由に書いていただき、読者の皆様にセキュリティの多様性と楽しみを感じ取れるようなサークルを私は目指しています。

最終的には、著者も読者も等しく当サークルの参加者と考えており*2、文章を通じて読み手と書き手が交わることで、一見特別に見えるセキュリティと他の領域の間にある壁を薄くし、交差する領域を実社会でも増やせれば最高です。

よって、ここでは私の書くことのみを紹介します。他の著者の内容は別途SNSなどで紹介いたします。 また、著者も絶賛募集中です!

ken\dscalが書くこと

私が何を書くかというと、今まではFIDO/OAuth/OIDC/FAPIなどの認証認可周りを書いてましたが、今回はお休みします。いや、正確に言うと認可には違いなにのですが、OAuthのような認可委譲の話ではなくクラウドネイティブやゼロトラストにおける権限ポリシーのエンジンについて書く予定です。どれくらい余裕があるかにもよりますが、平成の情シスおかしん@技術書典6さんの書く「ゼロトラストアーキテクチャ超入門」のうちの一部にフォーカスを当てた内容になります。

twitter.com

ご期待ください。

過去の作品

boothよりお求めいただけます。

https://booth.pm/ja/search/セキュア旅団

ぼやき

前回の技術書典5では「あ10」に配置だったのですが、壁際&角だと隣のサークルさんに並ぶ列が垂直に交わり、人の流れがこなかったんですよね...今回もリアル壁際なので同じ事にならないか心配です。ちょっとな〜...

g

f:id:kengoscal:20190225010155p:plain
前回の位置

f:id:kengoscal:20190225010407p:plain
今回の位置

っていうか、前回と今回で対角線上に配置されるの面白すぎない?

*1:当サークルのセキュリティはサイバーに限りませんが

*2:書いててこれがコミュニティ?って思った

「セキュア旅団」は技術書典6に出店します

TLDL

  • 技術書典6にセキュア旅団として出典します
  • 場所は「え01」です
  • 著者は第一線で活躍している方がそれぞれ自信が注目・取り組んでいるセキュリティのことを好きに書きます
  • すでに10人弱いますが、引き続き著者を募集中です。

f:id:kengoscal:20190225005415p:plain

主題

当サークルの目的

私が参加している「セキュア旅団」の技術書典6当確が決まりました。当日は「え01」にいますので是非起こしください。 思い出せば技術書展3に参加してから早3年なので、改めて当サークルが扱う内容について紹介します。

当サークルは名前の通り、セキュリティをメインに扱うサークルです。しかし、それを1つのトピックに限定することはしておりません。それは、主軸が異なる方にもセキュリティの多様性と楽しさを知っていただきたく事が目的だからです。

これは、NSCが開催しているサイバーセキュリティ月間が謳っている「みんなでしっかりサイバーセキュリティ」*1にも近いのですが、当サークルはよりグロースマインドセットな方向性を攻めて見たいと思っています。

どういうことかというと、当サークルにご参加いただいている著者に「自分(著者)の好きな・夢中になれる・楽しいと思えるトピック」を自由に書いていただき、読者の皆様にセキュリティの多様性と楽しみを感じ取れるようなサークルを私は目指しています。

最終的には、著者も読者も等しく当サークルの参加者と考えており*2、文章を通じて読み手と書き手が交わることで、一見特別に見えるセキュリティと他の領域の間にある壁を薄くし、交差する領域を実社会でも増やせれば最高です。

よって、ここでは私の書くことのみを紹介します。他の著者の内容は別途SNSなどで紹介いたします。 また、著者も絶賛募集中です!

ken\dscalが書くこと

私が何を書くかというと、今まではFIDO/OAuth/OIDC/FAPIなどの認証認可周りを書いてましたが、今回はお休みします。いや、正確に言うと認可には違いなにのですが、OAuthのような認可委譲の話ではなくクラウドネイティブやゼロトラストにおける権限ポリシーのエンジンについて書く予定です。どれくらい余裕があるかにもよりますが、平成の情シスおかしん@技術書典6さんの書く「ゼロトラストアーキテクチャ超入門」のうちの一部にフォーカスを当てた内容になります。

twitter.com

ご期待ください。

過去の作品

boothよりお求めいただけます。

https://booth.pm/ja/search/セキュア旅団

ぼやき

前回の技術書典5では「あ10」に配置だったのですが、壁際&角だと隣のサークルさんに並ぶ列が垂直に交わり、人の流れがこなかったんですよね...今回もリアル壁際なので同じ事にならないか心配です。ちょっとな〜...

g

f:id:kengoscal:20190225010155p:plain
前回の位置

f:id:kengoscal:20190225010407p:plain
今回の位置

っていうか、前回と今回で対角線上に配置されるの面白すぎない?

*1:当サークルのセキュリティはサイバーに限りませんが

*2:書いててこれがコミュニティ?って思った

セキュリティエンジニア in スタートアップが大事にすべき3つのポイント

FOLIOアドベントカレンダー ラストの個人投稿3回目です。過去2回は当社で利用しているプロダクトについてお話しましたが、今回は本ブログでも初のポエムになります。

adventar.org

セキュリティエンジニア(以降、エンジニア)がユーザー企業のスタートアップに転職したケースを目にする頻度が増え、時代の節目のようなものを感じます。

もちろん、昔からそういったスタートアップに参加するエンジニアはいたと思いますが、パブリックな情報として流れることは少なく、ましてや、経験した本人による体験談・ポエムは目にした記憶は全くありません。

そこで、今回はキャリアの選択肢の1つであろうスタートアップへの就職についての理解を深めるため、私の 超個人的経験と見解 をもとに、スタートアップで働く際に大事にすべきポイントをお話します。

どういうポジションから語るか

主観的な意見を述べるということは一定のポジションを取ることになりますので、最低限のバックグラウンドを共有させていただきます。

来歴

  • 2011年: 某Nなセキュア。MSS/CSIRT/SOCに従事
  • 2014年: 某MでFなFintech企業。創業2年目に参加して上場まで、社員数 50 -> 300を経験。モバイルアプリ開発とセキュリティ(なんでも)に従事
  • 2018年: FOLIO。創業2年目。セキュリティ(なんでも)に従事 <- 今ここ★

スキルセット

  • Blue成分多め。Red成分はGPENとWeb診断をツール回してできるくらい。
  • 今後攻めていきたい分野
    • AWS/GCP
    • CNCF系
    • OIDC/FIDO/Open Banking/Decentralized Identity/Self-sovereign Identityのような本人確認・認証・認可まわり

定義

  • スタートアップ: 創業数年で、新たなビジネスモデルを開発して市場を開拓する段階の企業(コピペ)。セキュリティ専任はいない。

このような人間が超主観的に語るので、1㍉も賛同できない方はきっといると思います。そういった方は是非、別の経験と真実を共有いただければと思います。では、本題に入ります。

本題: スタートアップに入る際に大事にすべき3つのポイント

順番に紹介していきます。

VisionとCultureへ共感する

Visionはスタートアップが目指したい世界観であり、Cultureはその構築・運営時における価値観です。 そういった参加先のVision/Cultureにある程度、共感・納得しておくことが大事だと思います。 これは、リスクの多いスタートアップはは、ある程度の覚悟とその先にある世界観へ希望を持ってことにあたる必要があるためです。

どのようなリスクがあるのでしょう?まず事業リスクです。 よく言われることですが、創業から3年後のスタートアップは約50%が失敗します。そもそも市場の開拓 = 不確実性の高い領域で勝負するのですから、勝負に負けた場合、転職1年目で会社が潰れてしまうことだってありえます*1

f:id:kengoscal:20181225175336p:plain
Years in existence

*2

事業リスクのような外部だけでなく、社内部にもリスクはあります。 大きなリリースに向けた長時間勤務のような話がまずあげられます。ですが、これはスタートアップでなくともある話です。成長過程のスタートアップしかないリスクだと、いわゆる成長痛による社内の雰囲気の悪化などがあります。例えば、人事評価や組織の階層化の構築・運用開始時におけるメンバー間のスタンスの違いや、あるいは現在進行系の案件とVisionへのギャップを感じたコアメンバーの離脱などが挙げられます。

セキュリティエンジニアにとっては(プレイヤーとしての)成長の機会損失リスクです。確かにスタートアップは身軽ですが、身軽さ故に良くも悪くもおざなりになってる施策があります。そのボール拾いが最初の1年間のお仕事になる覚悟は必要です。例えば...

  • 使い回されたパスワードの撲滅
  • ばらまかれた特権の整理
  • 整備されていないワークフローの洗い出し
  • 業務端末一覧化
  • 私用端末の撲滅

これらは最高に泥臭いですが、拾わなければいけないボールです。技術的なチャレンジはないただ淡々とこなす作業です。もちろん創意工夫の余地があることは否定しませんが、そんな余裕は普通ありません。技術にチャレンジする機会がすくないため、1人のエンジニアとしての技術的な成長をあきらめる一定期間というのは確実にありあmす*3

このように、スタートアップには様々なリスクがあります。そのような環境で働くことに本当にそれだけの価値があるのでしょうか? それを見出すのがVisionとCultureです。なにも100%共感すべき、ビジョナリーカンパニーのように信望しろ、と言いたいわけではありません。 きたるツラミと戦うには一抹の希望を胸に抱かなければならなく、そのためにはVisionとCultureへの共感と納得が必要なのです。

多面的・多角的なインプットをする

スタートアップに入るセキュリティエンジニアは、おそらく最初のセキュリティエンジニアです。 そんなエンジニアにとっての最大の味方は上層部です。Visionを実現したい上層部はきたるリスクに対処する専門家の味方です。他のメンバーも同じです。

ただ、ちょっと穿った見方をすると「セキュリティなら仕方ないよね」という言い訳が通りやすい環境で、もっと穿ってみると専門家に物申す批判者が少ない環境です。

最高なUsableなセキュリティを実現しても、それが業界のレギュレーションに準拠していないならば、それは業界内の独り相撲です。逆にレギュレーションにきっちり100%沿っていても、実装がスタートアップの実態にあってないこともありえます。

https://pbs.twimg.com/media/CT7GyGQWUAAhGlm.png

技術が、規制が、コンプライアンスのうち何が優先度たかいのかという話ではありません。エンジニアがボトルネックである、という話です。1人の人間として得意とする or できることが、必ずしも全体における最適な選択肢ではない可能性があります。そして、ある選択肢を選んだエンジニアに突っ込める人はスタートアップでは本当に少ないのです。そのため、エンジニアの一面的な知識・経験ではそれ自体がリスクになる可能性があります。

したがって、エンジニアは最新技術のインプットのみならず、 フレームワーク*4やら業界規制やら社内の状況やらを様々な側面から入手・分析し、知識として蓄え、然るべき時に然るべきアウトプットを出せるようにしなければなりません。研ぐ対象が爪だけではなく、牙もわざマシンも魔具を準備しておくのです。

ビジネスとセキュリティのゴールをアライメントさせる(あるいはしているか確認する)

さて、エンジニアとして頑張った甲斐あって(?)会社も軌道にのったとしましょう。確実にその成長に貢献したと思っているところに、評価者から次のようなありがたいコメントを頂戴することもあります。

「何も成果をだしてない」

これはエンジニア本人にも評価者にも非常に悲しいことです。しかし、感傷的になっても生産的ではありません。原因を考えてみましょう。 恐らく、根本的な原因は評価者とセキュリティエンジニア間のゴールの共有不足ではないでしょうか。評価者はメンバーの貢献具合を計測します。そこには数字があり、スケジュールがあり、ロードマップがあります。セキュリティサイドにそれがない場合、またあっても共有不足で認識されていなければ、いくら貢献したと思っても評価されないのです。

せっかく使い回しのパスワード撲滅や全社2要素認証導入など泥臭い、しかし大事な作業をしたところで、その成果を認められなくては悔しくて夜も眠れないでしょう。悲しい思いをしたくないのであれば、セキュリティの戦略を作った上で、ビジネス上の戦略とのアライメントをとれるよう、密なコミュニケーションで働きかけましょう。ラフでもするのとしないのでは天地の差があります。

まとめ

スタートアップという特殊な環境にいる、特殊なセキュリティエンジニアだからこそ大事にしたい3つのポイントを共有させていただきました。この情報がスタートアップに対する転職の流動性にポジティブに働くかネガティブに働くかはわかりません。しかし、これをもとによりリアルなキャリア選択ができるようになることをのぞんでいます*5

*1:そうなった方にこの間お会いした

*2:https://www.fool.com/careers/2017/05/03/what-percentage-of-businesses-fail-in-their-first.aspx

*3:個人活動は別

*4:例: https://csrc.nist.gov/Projects/Risk-Management

*5:できれば、一緒に働きましょう

AzureADでYubiKeyを管理しつつ認証(TOTP)する #azureAD #yubikey

FOLIOアドベントカレンダー 8日目、個人投稿2回目です。

adventar.org

8日に当社の勉強会「Scramble!」に来ていただいた皆様、ありがとうございました。

folio.connpass.com

FOLIOの情報戦略のこれから_-_情報システムを添えて.pdf - Speaker Deck

その場でお話した通り、当社はMicrosoft365を中心にした社内基盤へ生まれ変わろうとしています。 Microsoft365のIdP「AzureAD」は柔軟かつ強固なMFA方式を自由に選べます。通知ベースのMFAもデフォルトでついてくるスグレモノです。*1 特に10月からPublic PreviewになったハードウェアキーによるTOTPは、自分にとって嬉しいニュースでした。なぜなら、何らかの理由でスマホを使えないメンバーに、完全に独立したセキュリティキーをお渡しできるからです。 そこで本エントリでは、それについて触れてみようと思います。

techcommunity.microsoft.com

手順としては次の通りになります。ただし、ベンダーからバルクで購入する場合、1は不要になるようです。2までやってくれるかは原文からよみとれませんでした。

  1. YubiKeyに対するシードの設定
  2. YubiKeyとユーザーのヒモ付情報のAzureADアップロード
  3. 登録されたYubiKeyの有効化

YubiKeyに対するシードの設定

Yubikey Command Manger (CLI) を使って、シードをYubikeyに設定します。

% ykman oath add ken5scal@example.com
Enter a secret key (base32): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
A credential called ksuzuki@folio-sec.com already exists on this YubiKey. Do you want to overwrite it? [y/N]: y

YubiKeyとユーザーの紐づけたCSVファイルをAzureADにアップロード

さきほどのシードを登録したYubikeyをAzureADに登録します。その際に、下記のようにそのYubikeyとユーザー(UPN)を紐付けることができます。

upn,serial number,secret key,timeinterval,manufacturer,model
ken5scal@example.com,111111,SECRET_KEY,30,YubiKey,HardwareKey

f:id:kengoscal:20181207211959p:plain
アップロード先

登録されたYubikeyを有効化

アップロードが成功したら、対象のYubiKeyを有効化します。 f:id:kengoscal:20181207212419p:plain

有効化する際に求められるOTPは、Yubikeyを挿した状態のYubikey Authenticatorに表示される値を入力すればOKです。

f:id:kengoscal:20181207213420p:plain

同様にYubikey Authenticatorで表示された値を用いて、ログイン(2段階目)をできます。

f:id:kengoscal:20181207214921p:plain

このようにして、Azure ADに対してYubikeyでOTPすることが可能です。

終わりに

実はいくつか制限があり、現在は1人に付き5デバイスまでしか設定できません。また、これは私だけかもしれませんが、一回登録を解除(削除)したYubiKeyはたとえシードを再設定したとしても、最有効化できないようです(失敗します)。Public Previewだからかもしれません。

とはいえ、やはり一番めんどくさいのはシードの設定とCSVのアップロード、そして有効化の一連の作業です。情シスの身として考えると、そこらへんの工程はできるだけなくして欲しいと思います。将来的には個人向けOffice365アカウントやGSuiteのように、そもそもYubikeyを指すだけで完結するようなることを期待しています。

9日目は @laysakuraさんです

*1:Oktaは月$6追加料金がかかります