サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
ken5scal.hatenablog.com
今年は僭越ながら講師として招かれ、セキュリティ・キャンプ全国大会2019に参加してきました。 www.ipa.go.jp トラックBは、鈴木 研吾さんによる「ユーザー企業における情報システムとセキュリティ」です。ビジネスを継続成長させる中で、経営的なお話、ゼロトラスト、サイバーセキュリティフレームワークなどを交え、どのようにユーザー企業内でのセキュリティ体制を構築運用していくか学びます。 #seccamp pic.twitter.com/86p5njvEyR— セキュリティ・キャンプ (@security_camp) 2019年8月16日 自分はユーザー企業のセキュリティ担当としての立場から、「運用と開発」トラックの一部を担当し、「ユーザー企業における情報システムとセキュリティ」というタイトルで講義させていただきました。 4時間という長丁場でしたが、受講生の皆様にご参加いただいて嬉しかった
個人的に認証・認可まわりに興味を持ち出して以来、RFCやドキュメントを読みまくっていた。しかしながら、仕事が忙しかったり、そもそもここらへんを仕事でやるポジションにいないため、ちゃんと実装してみないことにはどうにもならんな、と思いだした。よって、最終的なゴールを雑なFAPI*1準拠したOAuth/OIDCシステムを実装していくことにした。具体的には以下の順番でやろうとしている。認証はもしかしたら、以前つくったFIDO2サーバー使うかも。 OAuth2.0クライアント(Code Grantのみ) OAuth2.0認可サーバー OAuth2.0リソースサーバー FAPI Part1化 OIDC化 FAPI Part2化 まずは、OAuth2.0クライアントを雑に作成した。ある程度できたので、一旦、棚卸しもかねてブログを書く。 その過程で湧いた疑問は、解を求める終わりのないRFC・ドキュメント漁
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: Ma
FOLIOアドベントカレンダー ラストの個人投稿3回目です。過去2回は当社で利用しているプロダクトについてお話しましたが、今回は本ブログでも初のポエムになります。 adventar.org セキュリティエンジニア(以降、エンジニア)がユーザー企業のスタートアップに転職したケースを目にする頻度が増え、時代の節目のようなものを感じます。 もちろん、昔からそういったスタートアップに参加するエンジニアはいたと思いますが、パブリックな情報として流れることは少なく、ましてや、経験した本人による体験談・ポエムは目にした記憶は全くありません。 そこで、今回はキャリアの選択肢の1つであろうスタートアップへの就職についての理解を深めるため、私の 超個人的経験と見解 をもとに、スタートアップで働く際に大事にすべきポイントをお話します。 どういうポジションから語るか 主観的な意見を述べるということは一定のポジショ
FOLIOのアドベントカレンダー1日目です。 adventar.org ブラウザから使える踏み台(Bastion)であるGravitational社のTeleportについて書きます。SSH秘密鍵を始めとしたクレデンシャル情報をローカルからなくす(もしくはクレデンシャルのアクセス権限を永続化させない)というのは、おそらくセキュリティに携わる人の課題の一つだと思います。 踏み台の文脈におけるその課題は、AWSではSession Manager、GCPではCloud Shellなどで実現しつつあります。Teleportもそのようなソリューションの1つと捉えることができるでしょう*1。 おそらく日本語の公開事例としては初でやったぜこれでホットエントリで間違いなし承認欲求万歳、とウキウキしながらアドベントカレンダーの準備をしてたら、クラウドネイティブのすだちくんに先を越されて泣いています。あー悔し
RSAカンファレンス2018のスライドが公開されていたので、ざっと一通りみました。 おもに私が面白い・役に立ったなと思うもののまとめをします。 オペレーション Incident Response In the Cloud クラウド上でSANS GCIHをするには、というテーマの発表です。Preparation, Detection, Containment, Recoveryのフェーズでの対応をクラウド向けに再構築しているもので、とても勉強になりました。 Preparation レスポンスチーム用のIAM ログ・エビデンス用のS3バケットの準備 全アカウントでのロギングやCloudWatch SGでレスポンスチームしか使えないインバウンドな通信。アウトバウンドは必要なときのみ開ける。 Detection SIEM, CASB CloudTral(API呼び出し元、時間、呼び出し元IPアドレ
Android アドベントカレンダー 20日目の記事です。 qiita.com とある同人誌に掲載する予定だったのですが、風邪でぶっ倒れて書けなかった最終章をこちらに書きます。 内容は、Firebase Authenticationを使った電話認証のあれこれです。以降、「Firebase Authenticationの電話認証」を電話認証として略させて頂きます。 また、本稿ではFirebaseの仕組み上、みんなだいすき2要素認証ではなく2段階認証と呼称させていただきます。 詳しくはこちらをご覧ください。 blogs.manageengine.jp 本稿は次の内容でお送りします。 - ベーシックな電話認証 - 既存アカウントとのヒモ付け - 電話認証を使ったなんちゃって2段階認証 - SMS Retriever APIを使った半自動2段階認証 では、やってまいりましょう。 ベーシックな電話認
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のベスプラに従ってなかった人は多いと思う。僕も
きっかけ ssmjpで発表してきました。最近、「NISTはSMSによる2段階認証を非推奨」という記事をよく見るようになりました。でも、それって昨年度のPreview版の話で、2017年7月のPublic版でもそうなの?という疑問がわいたので、根性だしてNIST SP800-63bを読んできました。 結論 Public版では非推奨ではありません。CISTによる指摘を、NISTが受け入れたようです。ただ、非推奨をそのまま取り下げたのではなく、SMSを超えて公衆交換電話網(PSTN)経路のOut-of-Band認証にスコープを広げ、「コレを使うならあれせいこれせい」といった諸条件を追加しています。このために、RESTRICTEDな認証と分類されています。ちなみに他の認証方式にRESTRICTEDに分類されたものはありません。 課せられた条件とは。 ちなみに諸条件は、下記の通りです。 RESTRI
(7/21) コメント欄の指摘を受け英訳追記 前文 本記事はGoogleのセキュリティ担当者 Parisa Tabriz氏(異名: Security Princess)のSo, you want to work in security?を翻訳したものです。 go for it!— Parisa Tabriz (@laparisa) 2016年12月25日 うっ…半年以上前… 意訳したりわからない部分もあったので、原稿の全てを反映できているか自信はありません。元ブログも是非ご一読ください。 —————————————- ここから翻訳 ————————————————- セキュリティ分野(コンピュータ、情報、サイバー…etc)でキャリアを積みたい人からメールをもらうことがある。素晴らしいことだと思う。テクノロジーを安全にしていくパション、創造性を持ち、ハードワークをこなせる仲間はいつだって必要
DroidKaigi2017に登壇・運営スタッフ参加したので、その振返りです。 ドキッ★脆弱性 onCreate() から onDestroy() まで スピーカーとしての振返り 8000円の参加費をとる平日開催のカンファレンスなので気合いれてたつもりだ。 まずやったことは、OverViewの作成だ。1月頭にグワ〜っと各章のタイトルと順番をつけていった。この時点で講演時間は考慮していない。 次に、各章の締め切りとアウトプットする場を設けていった。具体的にいうと毎月開催されるPotatotipsなどの勉強会でLTをすることで、各章を完遂させた。例えば1月には、当時の体制や対応のタイムラインについてPotatotipsで話した。2月には脆弱性が生まれた原因を潰すカスタムリントを作って、やはりPotatotipsでLTした。同月には、セキュリティの勉強会で脆弱性の原因についてLTした。 最後に、
2016年12月までにGoogleが買収したセキュリティ企業を調べてみた。きれいな案件だけでなく、潰しにかかってるっぽいものもあって面白かった(小並感。企業買収をExitとするなら、対象企業がカバーできてないソリューションを開発するのがいいという事だけは分かった。アタリマエ。 要約 ソース: https://www.cbinsights.com/research-google-acquisitions 調達額は各々シリーズの最初が違うのでアテにしないでください。 種別は私ジャッジでつけました。 企業名 種別 買収日 調達額 GreenBorder Technologies エンドポイント防御・仮想化 2007/5/10 $18M Impermium アンチスパム・不正アクセス対策 2014/1/16 Interactive Security Group レピュテーションススコアリング 20
更新履歴 (6/15更新)下記にてpiyologが更新されているので、そちらを見つつ足りてない情報を加え、情報を再整理d.hatena.ne.jp (6/16更新)6/15午前から6/16 0時までに公表された情報を追加 (6/16 18:20更新)タイムラインを更新 (6/17 01:30更新)6/16から6/17 0時までに公表された情報を追加 (6/20 01:17更新)6/17から6/20 0時までに公表された情報を追加 (6/27 19:00更新)6/20から6/27 までに公表された情報を追加 イントロ 後でpiyologと答え合わせする用エントリ。 2016/6/14、JTBグループは株式会社i.JTBのサーバーに、外部からの不正アクセスがあったことを報告しました。 タイムライン*1*2 ここではすべて2016年内での出来事とします 日時 出来事 備考 3/15 i.JTBの
DroidKaigiで登壇 & スタッフしたから振り返るお おっきなカンファレンスで初めて登壇 + スタッフをやってみたので、色々考えてみる 発表資料はこちら 明日、敗訴しないためのセキュアコーディング from Kengo Suzuki www.slideshare.net 運営編 何故スタッフに応募したのか Android界に貢献したかったからです。今まで私をSOやGithub上のソースコードから助けてくれたAndroidエンジニアが集まるイベントなので、そこで私なりのコミュニティへの(今現在出来る)貢献をしようと思いました。今年からはライブラリを始めとしたコードレベルでの貢献もしたくおもってます。 何をした? 参入が遅かったため(12月かな)、基本的に英訳・当日対応(受付など)を主にしました。後、地味に公式アプリにContributorとして参加しています。おっかなびっくりでした
このページを最初にブックマークしてみませんか?
『Got Some \W+ech?』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く