Got Some \W+ech?

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

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

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

(翻訳)セキュリティで飯食いたい人向けの行動指針

  • (7/21) コメント欄の指摘を受け英訳追記

前文

本記事はGoogleのセキュリティ担当者 Parisa Tabriz氏(異名: Security Princess)のSo, you want to work in security?を翻訳したものです。

うっ…半年以上前…

意訳したりわからない部分もあったので、原稿の全てを反映できているか自信はありません。元ブログも是非ご一読ください。

—————————————- ここから翻訳 ————————————————-

セキュリティ分野(コンピュータ、情報、サイバー…etc)でキャリアを積みたい人からメールをもらうことがある。素晴らしいことだと思う。テクノロジーを安全にしていくパション、創造性を持ち、ハードワークをこなせる仲間はいつだって必要だ。金銭的な意味で、安定した生活を送れるようにもなるだろう。

他にも同じトピック（キャリア）で似たようなポストがあるが、私の経験から導き出した上流の考えを共有していこうと思う。

警告: 映画のような華々しさはない

実際の現場はハリウッド映画とは違う。私はハッカー映画やドラマは好きだが、私の仕事の経験上、映画のようなスリルでセクシーな場面には遭遇しない。 しかし、(恐らく他の職種もそうだろうが)セキュリティはとても刺激的で、チャレンジングな、そしてやりがいのある仕事だと思う。

完全もしくは標準的なカリキュラムなどない

セキュリティは広範で、インターディシプナリー(学問的横断)で、応用的な分野だ。セキュアなシステムをデザイン・構築する、それを攻撃する、検知する、など役割は多岐にわたる。そのなかに唯一無二で標準的なカリキュラムなどない。この分野がより成熟するにつれ、カリキュラムも充足してくるかもしれないが、私はそうなるとは思えない。

もし、あなたがコンピューターサイエンス、コンピュータ、ソフトウェアの仕組みを理解するのであれば、それらは大いに役に立つであろう。コンピューターサイエンスは抽象的なレイヤーの問題を解決する学問であり、セキュリティはその抽象レイヤーにおけるミスを見つけ直す（もしくは攻撃する）学問だ。

私はイリノイ大学のコンピューターサイエンス部で学んだ。中でもOS、ネットワーク、コンピューター・アーキテクチャ、コンパイラーなどのコースが役に立った。それに加え、私が興味をもった技術コース（信号処理、バイオメディカル工学、人工知能）や、インターン、学生クラブのプロジェクトで携わったネットワーク、プライバシー向上技術、Web/クライアントアプリ作成などで経験と積んだ。

ユーザーや顧客がどのようにテクノロジーを使うか理解するのも有効だ。もし私が大学に戻るのであれば、心理学、社会学、ヒューマン・ファクターのコースをとるかもしれない。

私は似たようなバックグラウンドを持つ専門家とも、そうでない専門家とも仕事をしたことがある。専門家には学位を取る前に中退した人もいる。

私は特にセキュリティの資格をもっていない。それによって不利益を被ったこともない。なにかしらの産業や国ではプロフェッショナルとして必要かもしれない。they’re certainly a thing that some reasonable people have pursued — caveat emptor(?) -> 持っていた方が雇い主が安心できるケースはあるかもしれない。

ハッカーの文化を理解するために、Hacker ManifestoやHow to Become a hackerを読むといいだろう。セキュリティ専門家の行動指針・行動規範になるだろう。もし、ハッカーでなくても、ハッカーのマインドセットを理解するのに役立つはずだ。

他にも色々なインプットをする場がある。私がインプットする先はこのTwitter security listにいるひとたちからであることも多い

手を動かせ。実践しろ。

どの業種でもいえることだが、業務経験はなるべくはやく始めることだ。始めることで興味、強み、将来のキャリアプランを計画できる。日常業務や環境がどういった要素から構成されており、そのうち何が好きで何が嫌いか学べる。私の人生で最も価値があった経験の一つは、おおよそ全く好きになれなかったインターンシップだ。私の将来の方向性は大きく変化した。

どのように業務経験を始めるかは人による。学生クラブやキャリアフェアに出席し、熱意を向けられるインターンシップやバイトに応募しよう。私の場合、ライフガードコミュニティでやっていた清掃バイトの伝手で、大学寮のシステム管理業務をやることになった。ここで積んだ経験を活かし、大手製薬会社でITインターンをすることになった。また、授業ではなく大学のクラブ内で実際のソフトウェア作成の経験をつみ、サイバーセキュリティインターンシップをみつけた。こうやって私は、Googleの中のひとに「どれいっちょ面接するか」と思ってもらえるぐらいの経験を積んだ。

コードを書け

私の知っている優秀なセキュリティエンジニアは、コードをよく書く。ソフトウェアを書くことで、セキュリティ的なバグを埋め込むこともある。この過程から開発者に対してリアルな共感をもつことができるのだ。結局のところセキュアでないコードを指摘するより、継続してセキュアなコードを作っていく方が難しいことを認知できる。

もし、どこから始めれば良いのか分からければ、オープンソースのバグを潰すところから始めるといいだろう。バグ潰しは感謝される。プロジェクトのメンバーに感謝されるだけでなく、将来的な仕事につながることもある。

コードを壊せ

ソフトのバグを探すことに時間を費やせ。デバッガ・ネットワークスキャナー・ウェブプロキシ・ソフトウェアfuzzerの使い方を学ぼう。ハッカープレイグラウンドで遊ぼう。私は大学の時、http://seclists.org/bugtraq Hack This Site!をつかっていた。他のハッカー養成場は https://infosec.rocks.にリストされている。CTFなどのハッキングチャレンジりすとはここだ。バグバウンティをやっている会社にばぐを報告するのもよいだろう。

バグを探すだけでなく、bugtrag/fulldisclosure/oss-secから他者がみつけたことを追い、学ぶことも推奨する。

知識を共有しろ

私は大学時代に、ACMグループのSigMil(?)にいた友人からセキュリティを教わった。そこでは興味のある分野についてプレゼンをするメンバーがいた。我々はまた、DEFCONへ巡礼したり、セキュリティ本を買ったり、外国の同じ志をもつ同士と成果物についてチャットしあったりした。Googleでは、専門性・苦心していること・半熟なアイディアを同僚と共有することで、たくさんのことを学べた。

知識の共有はいくつかの理由で重要だ。 1. 知識の共有は、セキュリティのベストプラクティスやハマリポイントを横断的に展開していくのに有効だ。 2. プレゼンやドキュメントの作成の過程でたくさんのことを学べるので、隠れたトピックまで見渡せられる 3. 質問・コメント・ディスカッションを通して、聴講者からも学びがある。 4. Pay it forward(?) -> その恩は周囲の人にも広がる

本当にたくさんのことを学んだ。

コミュニケーションを怠るな

セキュリティをするということは、同じバックグラウンドを共有しない人に対して、複雑な技術的問題を日常的に説明することになる。そして、聴講者はそれぞれ異なる単語・専門性・動機をもつことになるだろう。あなたは脆弱性の重要さについて国際的な基準にたよることは滅多にできないし、セキュリティのプラクティスを実践するときに、輝かしいデモはできない。あなたは、聴講者にフラストレーションを感じさせてはならない。

これをするにはコミュニケーションが必要であり、時には説明と交渉をしなければならない。技術的リソースだけでは身につかないため、練習し、パブリッシュし、継続的に向上させていかなければならない。

辛いことも失敗もある

当たり前のことだが、明確にしておきたい。 セキュリティは大変な仕事だ。我々が古いものを撤廃するより圧倒的早く、我々が守るべき技術分野は変わる。従って、新しいことを学び続けねばならない。攻撃者は我々より時間とリソースを持っており、既存の防御手法にも追いつきやすい。

セキュリティはストレスの多い仕事だ。不明瞭な問題や不完全なソリューション、あまりないデータ、何より人の安全を脅かす現実の脅威と向き合わなければならない。

セキュリティは成功を可視化しにくい仕事だ。私の経験上、失敗の方が人の目につきやすい。だが、我々は究極的にリスク緩和までしか対応できず、銀の弾丸は存在しない。

楽観者でいよう

先述の通り、 (‘A`)ｳﾂになることもあるであろう。テクノロジーの進歩についていけないと思うかもしれない。2016年の今日でもバッファオーバーフロー脆弱性を利用して、インパクトのでかい攻撃をされている。セキュリティは不可能であり、悪くなっており、なぜ我々が失敗してるか指摘する人を良く見ることになるだろう。

現実は辛いかもしれない。だが、テクノロジーが我々にもたらしたことを考えてみよう。その成果はすばらしいの一言だ。もちろん完璧ではないし、将来的にも完璧にはならない。だが、セキュリティは10年前より確実によくなってるし、それなりのレベルで保証されるようになってきている。だから私は楽観者でいられる。

助けを求めよう

嫌な奴はいる。嫌な奴にくじかれるな。男性優位主義でエゴイスティックな側面を長いことみてきた。会話がマウント取りに発展することは珍しくない。

私の今までの成功は、他のセキュリティ専門家の人の支援・アドバイス・教育からなっている。助けを求めても、それは仕事から外されるということではない。

なので、助けが必要であれば聞こう。デューディリジェンスをちゃんとし、助けを提供しやすいようにしよう。スコープを適切に切って、コンテキストを共有し、タイポを減らせば、良いレスポンスが返ってくるはずだ。

Good luck and happy hacking!

チェキしたいセキュリティ系スタートアップ - 2017年編

セキュリティ
  • 1月から書こうと思ってた内容をいまさら書くという。
  • 多分偏ってる。
  • 所感: 大体のサービスにおいてポリシーをもとに設定するという文が目立った。恐らく会社のポリシーがあることが前提になるので、それをしないで導入しても所謂運用でカバーするみたいな残念な結果になると思われる。まずは頑張ってポリシーを作ろう。
    • ポリシーをコンフィグにして、それが設定に反映されるソリューションかはちゃんとチェックしてない

Argus Cyber security

  • 車セキュリティ
  • 車どころか免許も持ってないザコなのでスルー

Bitglass

  • CASB
  • エージェントレスらしい
    • Netskopeはどうだったっけ
  • セキュアアクセスが可能
    • これがどういう意味での「セキュア」かは調査してない

Bromium

  • EDR(といっていいのか？）
  • エンプラデスクトップ向け仮想化ソリューション。
  • ファイルを開くと仮想環境上で開く。
  • 勝手にマルウェアを隔離し、ダッシュボードを作る。これによってマルウェアに関連するキルチェーンが可視化される

Cyence

  • サイバーリスクモデリングツール
  • Financial impactの算出を実行
  • 保険会社向け

Darktrace

  • エンプラネットワーク内でのActivityを異常検知& 自己学習

Demisto

Druva

  • クラウドデータプロテクション
  • 各種クラウドストレージのバックアップとしても昨日するっぽい
    • リモートオフィスからも、アプリからも
  • データガバナンスにも、コンプライアンス分析もできる
  • Accessトークンの監視など、今時の開発・運用環境に利用できそう
  • bitglass, demistoと合わせて俺の中で熱い

Eviden

Fugue

  • クラウドプラットフォーム(ex: AWS)上で
    • スタンダード・ポリシーに従った設定を反映
    • 変更管理のトラッキング
  • Terraformとどう違うのかな?

Illusive Networks Ltd.

  • Deception Technology
  • データのハニーポットみたいな(命名 by Kengo)
  • Creates an alternative reality transparently woven into your existing network

Insights

  • 機械学習を活用した攻撃検知・分析・封じ込めプラットフォーム
    • インシデントレスポンスプラットフォーム
  • Demisto, Phantomとかぶる？

Kenna

  • 脆弱性トリアージ、リスク分析、レポート
    • リスク分析って聞こえはいいけど、スコアリングシステムの中身知らないと意味ない気がする今日このごろ

LogicMonitor

  • SaaSベースのパフォーマンス監視サービス
    • PrometeusとかGoogle StackDriverではできないことがあるのだろうか？

NetSkope

NEXThink

  • 端末ベースのネットワーク・サービスの可視化、
  • 分析・インテリジェンスプラットフォーム
  • SIEM/SOC統合もあるよ！

Onion ID

  • 特権管理SaaS。
  • 各種Web管理画面のJust-In-Time Privilegesもできるっぽい。
  • 振る舞い検知もするらしい。
  • 個人的にホットな分野だが、当該企業の情報が少ない

PerimeterX

  • 振る舞い検知型のWeb系攻撃の防御
    • Botによるサービス・アプリへの自動化された攻撃を防御するっぽい

Phantom

Prevalent

  • 3rdパーティ・ベンダーの自動リスク分析・脅威監視

RiskIQ

  • ユーザーをフィッシングサイトなど、自社サービスを装ったものを監視する

Silent Circle

  • eメール、スマホ、テレカンを通したセキュアな通信
  • PGPのPhil Zimmermanがいる
  • よくわからん。

StackPath

  • セキュアCDN/WAFのプラットフォーム
  • Fastly/Akamai Konaとどう違うのか？

Skybox Security

  • 分析・インテリジェンスプラットフォーム

360 Mobile Security

  • モバイル向けセキュリティソフトのパッケージ
  • あんまり興味ないかな…

Refs

GCP + k8sで共有registryからコンテナImageを読み込む #gcp #メモ

プロジェクト毎にregistry作るの意味なくね？と思ったので、ほぼ全てのコンテナImageをアップロードしたregistry付きプロジェクト(以降project-reg)を作った。 ここに対してImageをpullするには、docker login -e相当のことをpodでしなければならない。

Service Account on GCPを作成

project-regにroles/storage.objectViewerロールの付与されたService Accountを作成。 Terraformだと↓。

resource "google_service_account" "container_registry_reader" {
  account_id   = "docker-image-reader"
  display_name = "Docker Image Reader(Puller)"
}

resource "google_project_iam_policy" "project_owner" {
    project = "${var.project_id}"
    policy_data = "${data.google_iam_policy.image_puller.policy_data}"
}

data "google_iam_policy" "image_puller" {
    binding {
        role = "roles/storage.objectViewer"
        members = [
            "serviceAccount:${google_service_account.container_registry_reader.email}",
        ]
    }
}

該当Service Accountのkeyを作成

Terraformのやりかたはわからなかった。

gcloud iam service-accounts keys create docker-image-reader-secret.json --iam-account=docker-image-reader@project.iam.gserviceaccount.com

Kubernetesにシークレットを作成

% kubectl create secret docker-registry gcr-pull-key --docker-email=docker-image-reader@project.iam.gserviceaccount.com --docker-password="$(cat docker-image-reader-secret.json)" --docker-server=https://gcr.io --docker-username=_json_key

PODのサービスアカウントを更新

% kubectl get sa default -o yaml > ./service_accounts.yaml
% vim service_accounts.yaml
# [delete line with key "resourceVersion"]
# [add lines with "imagePullSecret:"]
% kubectl replace sa default -f ./service_accounts.yaml

PODのコンテナ更新

% vim deployment.yaml
% kubectl replace --filename ./deployment.yaml

GCP上のプロジェクトをTerraformで作成する #GCP #Terraform

GCP terraform メモ

追記

  • 2017/05/12: 下記の備忘録は正確ではない可能性がある。下記の設定を実際に反映させてないのに、プロジェクトが作成できたから。

本編

GCPの備忘録を作っていこうと思う。 今までプロジェクトを2個つくり、最初は GUIでポチポチと、２個目は極力gcloud と kubectlだけで作成をした。今回は可能な限りTerraformをつかい、記録を残したいと思う。 というわけで、プロジェクトの作成から。

いきなりTerraformから逸脱してしまうが、ProjectをTerraformから作るにあたり"roles/resourcemanager.projectCreator"が付与されたIAM Policyが必要だ。これを個人メアドに割り当てることもできるが、冗長性や拡張性を意識しグループメアドに割り当てるのが得策だとかんがえる（システム用アカウントは極力作りたくない）。

ので、まずGsuiteでグループメアド(infra-admin@hogehoge.com)を作り、そこにインフラに携わる人間のアカウントを追加する。そして、iam_policyを作る

gcloud alpha organizations add-iam-policy-binding ${ORG_ID} \
            --member='group:infra-admin@hogehoge.com' --role='oles/resourcemanager.projectCreator'

これをTerraformで記述する

data "google_iam_policy" "admin" {
    binding {
        role = "roles/resourcemanager.projectCreator"
        members = [
            "group:infra-admin@hogehoge.com"
        ]
    }
}

後は、providerとproject.tfを書けば、おｋ

// Configure the Google Cloud provider
provider "google" {
  project     = "${var.project_id}"
  region      = "${var.region}"
}
resource "google_project" "proj-hoge" {
    project_id      = "${var.project_id}"
    org_id          = "${var.org_id}"
    name            = "${var.project_id}"
}

Plan & Apply

% terraform plan
% terraform apply                                                                 (git)-[master]
data.google_iam_policy.admin: Refreshing state...
google_project.proj-hoge: Creating...
  name:        "" => "gcp-hoge"
  number:      "" => "<computed>"
  org_id:      "" => "${ORG_ID}"
  policy_data: "" => "<computed>"
  policy_etag: "" => "<computed>"
  project_id:  "" => "gcp-hoge"
  skip_delete: "" => "<computed>"
google_project.proj-hoge: Still creating... (10s elapsed)
google_project.proj-hoge: Creation complete (ID: gcp-hoge)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

以上。

Railsアプリ(Production)のシークレットキーをGKE & k8sに読み込ませる

An unhandled lowlevel error occurred. The application logs may have details.

kubectl create -f services hogehoge.ymlし、公開IPにアクセスした際に出た表示↑ Application系のエラーらしいので、kubectl logs -f [POD_NAME] [IMAGE_NAME]でログを流してみたら、config/secrets.ymlにsecrete_key_baseが設定されてないとのこと。

見てみると、SECRET_KEY_BASEという環境変数にシークレットキーを設定していなかった。ちなみにアプリを開発してるのは別の人で、自分はWebアプリにあまり詳しくないマン。 　

% cat config/secrets.yml                                                                           
default: &default
  secret_key_base: XXXXXXXXXXXXXXXX

development:
  <<: *default

test:
  <<: *default

production:
  <<: secret_key_base: <%= ENV['SECRET_KEY_BASE'] %>

当然、SECRET_KEY_BASEにシークレットキーを設定してやればいいだけなんだけど、Githubに上がるのであればDockerfileやapp-deployment.ymlなどにはべた書きにはできない。なので、k8sでそのシークレットファイルを作成・管理する。

% kubectl create secret generic app-secrets --from-literal=secret_key_base=`bundle exec rake secret`
% kubectl describe secrets app-secrets

ここで作られたシークレットをデプロイ中に環境変数としてセットするため、deployment.ymlを編集

% kubectl edit deployment/app
    spec:
      containers:
      - image: gcr.io/YOUR_REPO/YOUR_IMAGE:v1.0.0
        name: mds-web
        env:
          - name: RAILS_ENV
            value: production
          - name: SECRET_KEY_BASE
            valueFrom:
              secretKeyRef:
                name: app-secrets
                key: secret_key_base
% kubectl rollout status deployment/app

ロールアップが完了後、再度アクセスしてもんだいないことを確認。

余談

  • secretはk8sのマスターに格納されているっぽい。ここのセキュリティはどう担保しているのか気になる