Got Some \W+ech?

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

「Secure旅団」は技術書典7に参加します

「こういうセキュリティもあるんだぜ!」という著者の思いを読者に届け、「お、こういうセキュリティもあるんだ!」というWowと新しい知識を少しでも多くお届けする同人誌を作ります。セキュリティであればジャンルに拘らずバイナリからWeb、機械学習からレガシー、設計からエモ内容など様々な内容を提供します。

TLDR

  • 技術書典7に「Secure旅団」として出典します
  • 場所は「お51C」です
  • 著者は第一線で活躍している方がそれぞれ自信が注目・取り組んでいるセキュリティのことを好きに書きます

f:id:kengoscal:20190831181448p:plain
位置

techbookfest.org

主題

当サークルの目的

私が参加している「セキュア旅団」の技術書典7の当確が決まりました。当日は「お51C」にいますので是非起こしください。

当サークルは名前の通り、セキュリティをメインに扱うサークルです。 ただし、それを1つのトピックに限定せず、あえてバラバラにしています。 というのも、当サークルは「こういうセキュリティもあるんだぜ!」という著者の思いをのせ、購入いただいた読者に「お、こういうセキュリティもあるんだ!」と少しでもセキュリティの多様性とWowをお届けする同人誌を目指しているためです。 そのため、セキュリティであればジャンルに拘らずバイナリからWeb、機械学習からレガシー、設計からエモ内容など様々な内容を提供します。 各トピックは、おそらくそれ単体で1つの同人誌が作れるレベルのクオリティでしょう。

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

今回のトピック

過去の作品

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

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

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

セキュリティ・キャンプ全国大会2019に講師として参加してきた

今年は僭越ながら講師として招かれ、セキュリティ・キャンプ全国大会2019に参加してきました。

www.ipa.go.jp

自分はユーザー企業のセキュリティ担当としての立場から、「運用と開発」トラックの一部を担当し、「ユーザー企業における情報システムとセキュリティ」というタイトルで講義させていただきました。 4時間という長丁場でしたが、受講生の皆様にご参加いただいて嬉しかったです。 また、運営の皆様にも色々支援いただきましたので、この場をかりてお礼申し上げます。 ありがとうございました。

講義の内容

「運用と開発」トラックは「[世の中を自分たちの力で変えていきたい] (https://www.ipa.go.jp/jinzai/camp/2019/zenkoku2019_characteristic.html) 」といった強い目的を持った参加者が、 「きちんと運用する 」 ためのスキルを身につけるトラックでした。

そこで、 私は「世の中を変える」を「新しい価値を生み出す」ことと仮定し、価値を持続的に提供し続けるうえで、その障壁となるリスクに対してどのように俯瞰的にアプローチするかをテーマにしました。

昨今、スタートアップと大企業のような異なる規模、あるいは業種、時として金融産業と非金融産業がサービス提携するなど、いわゆるConnected Industriesな時代は既存産業の可能性を拡張すると同時に、 従来では想定しえなかった攻撃の道を舗装してしまいました。 皆さんもご存知の通り浸透しつつあった様々なFintech系サービスやHR系サービスで、そういったリスクの顕在化がここ1.5年で相次いでいます。

残念な事例ではありますが、価値を生み出す際には「Done is Better Than Perfecet」な思想だけではなく、同時にリスク対策も進めねばならないことが明白になったのではないしょうか。

そういった背景をふまえて、私が勤務していた証券会社やFintech企業での勤務経験や同僚から学んだことをベースに、前半では「法令・戦略・戦術・設計」で全体像を把握し、後半では「設計」について深堀りしたのが、私の講義です。  

前半: 法令・戦略・戦術・設計

総合的なリスク対策をするには、まず業界のルールをそもそも知らなければなりません。 法令(Act、Regulation)や標準(スタンダード、ガイドライン)はリスクベースな考え方になりつつあるとはいえ、 リスク受容するにはそれを知った上で受容しなければいけないからです。 本講義では、金融商品取引業者としての証券会社に関わる法令(例: 金商法、個人情報保護法)の紹介をしつつ、「金融商品取引業者等向けの総合的な監督指針」および「FISC安全対策基準」を標準あるいはガイドラインをして、遵守すべきルールを提示しました。

そして「FISC安全対策基準」と同じくリスクベースを前提にしている「Cyber Security Framework」を経営レベルでのアプローチとし、個別具体的な対策としては「ATT&CK」を、それぞれサイバーセキュリティ戦略・戦術として紹介しました。

後半: BeyondCorp

全体戦略と戦術はさておき、とるべき設計(あるいはアーキテクチャ)についてはここ十数年の間に大きくかわりました。

DMZをインターネットと社内NWの間に設置することで生まれた「Trusted Zone」をトラストアンカーとするビジネスIT環境は、以下のような移り変わりをしてきたかと思います。

  • 2003年頃: 経理・顧客管理などの業務システムのSaaS化 (Salesforceなどの)
  • 2006年頃: 基幹システムのSaaS化(GSuite, AWSなど)
  • 2010年頃: iPhoneの業務活用
  • 2014年頃: 大手企業とスタートアップの提携開始(第四次スタートアップブーム)
  • 2016年頃: リモートワークの広がり

このようにビジネス環境が、自社のTrusted Zoneから従来Untrusted Zoneとされていた領域に比重を移していったことにより、トラストアンカーとしての「Trusted Zone」の再定義を見直さざるをえない時代になっています。

そういった時代背景とともに、社内システムにおいてもセキュリティ設計を見直さなければいけません。 本講義では、新しいビジネス環境における設計の一例として「BeyondCorp」を解説いたしました。 具体的には論文内からBeyondCorpのエッセンスを抽出し、それぞれの要素、現実世界における各種ソリューション、そして現時点での制限(挑戦)を私の知る限り詰め込みました。

このようにして、新しい世の中を作る才能が、同時に発生するリスクへ俯瞰的なアプローチをできる教材を提供しました。

講義資料

公開にあたって特定の情報を削る・マスクするなどしています。 もし気になるポイントがあればDM ( @ken5scal )などに連絡ください。

speakerdeck.com

個人の感想

  • 応募者には全員参加してもらいたかった。選抜するときはかなり悩んだ。
  • 4時間分の資料を、0から作り上げるのを個人の時間でやるのは死んだ。
  • もし次のチャンスがあれば、ハンズオン形式にしたい。
  • リハやっていなければ即死だった。

願わくば受講生のみなさんがセキュリティの業務に就いたとき、「そういえばあの環境では @ken5scal があのような発言してたな」と、一瞬思い出していただければいいと思います。

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:書いててこれがコミュニティ?って思った