まだパスワード管理で消耗してるの？Bitwardenを使ってみた
パスワードってどうやって管理している人が多いのだろうか。
ブラウザやスマホのパスワード管理機能を使っている人はかなり多いと思うが、満足しているだろうか。
自分はここ1年ほど感じていた課題感からパスワード管理ツールとしてBitwardenを使ってみることにしたのでその動機にも触れつつ紹介してみることにする。
自分の従来の管理方法
これまではChromeはブラウザ用、iPhone(キーチェーン)はアプリ用という具合で、パスワード管理機能を併用して管理していた。
iOS版Chromeバージョン86 から、アプリでの自動入力にもChromeで保存しているパスワードが使えるようになったので、Chromeに集約することも可能ではあったが、バックアップの意図もあり両方で保管することにしていた。
しかし、ChromeにしてもiPhoneにしても、そもそも両者には物足りなさというか、いくつかの小さな不満があった。
URLがないと登録できない
ブラウザに付いている機能なので当たり前といえば当たり前なのだけど、ブラウザを通さず使用しているアプリのパスワードは自動で登録されないし、URLが必須項目なのでiPhoneで手動登録するにもダミーのURLを入力する必要がある。
自動登録が気まぐれ（iPhone）
iPhoneでキーチェーンへの登録は新規パスワード作成時であればだいたい「キーチェーンに保存しますか？」と提案されるが、既にIDを持っているアプリでログインをした時に、iPhoneに保存されていなければ必ず提案されるかと言えば、そういうわけでもないらしい。 URLを取れるかどうかで決まっているのかなど、仕様を把握できていないのであまり強く言えないが、ユーザ側としては気まぐれ感が強い。
まぁ手で登録できるのが救いではある。
自動登録しかできない（Chrome）
Chrome最大の泣き所がこれ。ログインした際に自動で登録してくれるのはありがたいのだけど、逆に自動でしか登録されないので任意に個別追加することができない。
ブラウザを使っているときはそれほどストレスにはならないのだけど、一度ログインをしないことには登録することができないし、アプリのパスワードは仕組み的に登録不可。
あくまでブラウザの補助的機能という位置づけなので仕方ないとは思うが、パスワード管理として見た時、自分で登録をコントロールできない時点で管理できているとは言い難い。
パスワード生成ルールに合わない
新規にパスワード登録する際に、Chromeではパスワードフォームを右クリックすると「安全なパスワードを自動生成」という選択肢が出てくる。iPhoneの場合は（というかSafariでは）「強力なパスワード」というものがフォームに自動入力される。
この機能はランダム文字列をパスワードに設定するのに抵抗さえなければ大変便利なのだが、時に文字数や文字種類数がそのサイトのパスワードポリシーに合わないことがあり、自動生成したものをそのまま使えないことがある。
しかもSafariの場合は提案されたその文字列の編集ができないので提案を却下して「独自のパスワードを選択」するしかない。
そんなわけで、各種パスワードポリシーに適合するパスワード文字列を生成できるツール（下記例）が手放せなくなる。
ただこのサイトもスマホ使用時には向かないし、そのためにわざわざ別アプリを探すのはちょっとダサいので、ワンストップで提供してほしい。
無料ツールへの依存
これは不満というか不安で、パスワード管理に限らずWebサービス全般に言えることだけど、ChromeもiPhoneキーチェーンも結局無料で提供されているおまけに過ぎないので（Googleには課金してるけど）、万が一漏洩してしまっても大した説明は得られないだろうし、垢バンやその他の理由である日突然使えなくなっても打ち手が限られてしまう。
漏れたり無くなったりするとメチャクチャ困る、重要な情報を預けるサービスであるからこそ、きちんとお金を払って価値提供を受けるべき、と以前から考えていた。
Bitwardenについて
有料のパスワード管理ツールも結構な数があり、最初は 1Password にしようと考えていた。
だが1Passwordはかなり前から名前を聞く老舗の認識（調べてみると初版が2006年6月）だったので、今ならもっと新しいイケてるサービスがあるのではないか？と思い対抗ツールなどを見ていくと、Bitwardenという 2016年8月に登場の新しいサービスが台頭しており、さよなら1Passwordみたいな書き方も見かけたので、使ってみることにした。
特徴（いいところ）
オープンソース
曰く、Bitwardenの最も重要な特徴であり、オンラインのセキュリティソリューションにとってコードの透明性は要件であるべきという信念があるとのこと。
オープンソースであることがセキュリティレベルを証明する要因の1つにもなっている。
なおセキュリティに関して補足すると、Bitwardenはサードパーティーのセキュリティ会社による監査を受けており、かつバグ報奨金プログラムを通じてセキュリティ研究者とのコミュニケーションも取っているとのこと。
また、もしBitwardenがハックされても、ユーザの保管データとマスターパスワードはAES-CECとPBKDF2を組み合わせた 強力な暗号化と一方向のソルトハッシュ 対策により保護されるため、安全だとされている。
（興味深いけど難しい...）
余談だが、BitwardenはAzureにホスティングされているらしい。Azureで大障害が起きたら使えない可能性はあるってことね。
無料
これが1Passwordユーザの乗り換えをも引き起こしている最大の要因だろう。どうせならきちんと課金したいと思いつつも、無料で使い倒してから考えられるというのはありがたい。
※1Passwordも無料トライアルはできるが14日間。ちと短い。
しかも有料版も1人で使うならたったの$10/年。安い！
1Passwordの$36/年も決して高くはないのだが、財布の紐に対するこの心理的ハードルの差は大きい。
パスワード生成ツール
他の有料ツールでもだいたいこの機能はあるのだが、やはりツール内で完結できるのは嬉しい。パスワード更新したいときもアイテムの編集画面からスムーズに新しいパスワードを自動生成できる。
最終的にサイトのパスワード入力欄に貼り付けるひと手間はあるが、それくらいはまぁセーフ。
パスワード履歴
例えばサイト内の複数サービスで同じパスワードで認証している場合などがあると、パスワード更新の際に上書きして以前のパスワードが消えてしまうのは少々不安がある。
Bitwardenではパスワードの履歴を5回分まで保持できるのでその心配からは解放され、遠慮なく上書き保存することができる。
TOTP管理
二段階認証ツールBitwarden Authenticator を提供しており、ログインから二段階認証までこれで完結（良し悪しは別として）。
二段階認証ツールは既にAuthenticatorやAuthyを使って必要なアカウントはほぼ設定してしまったので基本的には使っていないが、試しに1つ設定して使ってみた感想としては、、、Authyで十分かな。 ただAuthyと同じく端末依存せずに安全に、かつアカウントとセットで保存しておけるので、バックアップ的に新規で何か二段階認証を登録する際にはこっちにも入れてみようかな、くらい。
セキュリティレポート（有料）
Chromeには「パスワードを確認」機能（Googleパスワードマネージャーの「パスワードチェックアップ」）、 iPhoneのパスワード管理にも「セキュリティに関する勧告」があり、どちらも
- 漏洩（流出）したパスワード
- 使い回されているパスワード
- 脆弱なパスワード
この3種類の問題を検出してくれる機能があるので、ヤバいものがあった時に教えてもらうという基本的な要件は満たせるように思う。
Bitwardenではプレミアムアカウントに登録すると各種ヘルスチェックレポートが使えるようになるが、上記3種類の他に「非セキュアウェブサイト調査」「非アクティブ二段階認証」「情報漏えい調査」なんてものもあって興味深い。
2つほどイメージを紹介。
イマイチなところ
PCブラウザでのパスワード自動入力機能は、はっきり言ってChromeに搭載された機能の方が楽。
Bitwardenは Chrome拡張を入れていてもノータッチでフォームに入力はしてくれず、拡張機能のアイコン or 右クリックメニュー経由で最低2クリックほどは必要になってしまうのでUXはあまり良くない。
このあたり、1Passwordはフォーム上にアイコンを表示してくれるのでBitwardenにも欲しいところ。
ただこの点は、ショートカットキー（cmd+shift+L）で自動入力できるし、そもそも真っ先にChromeが候補を入れて表示してくれるので、明確なデメリットとして感じる機会が無いかもしれない。
導入後の管理スタイル
単一サービスへの1本足打法はどうしても不安な面があるのと、最後に挙げた自動入力の利便性の面から、結局今のところは Chrome, iPhone, Bitwarden を併用する形を取っている。
余計消耗してるじゃねーかというツッコミは甘んじて受け入れる。
1つアカウント登録するだけでも全ツールに手動同期することになるので面倒くさいが、もうしばらくこれで行こうと思っている。
他にできそうなこと、気になっていること
ID、パスワード以外に入力フィールドがあるサイトで、その要素を予め登録しておくと自動入力がキレイにできる。
- が、それが必要なサイトも限られているので、現状そこまでカスタマイズしていない。
- AWSのIAMログイン画面はアカウントID、IAM名、パスワード と3つ入れるところがあるので、カスタマイズしておくと幸せになれるかもしれない。
Bitwarden CLI で各種操作が可能とのこと。個人利用での活用イメージはほとんどないが、開発でExcelやスプレッドシートを使って管理しているテストアカウントの管理などをパスワード管理ツールに集約して自動化...とかには使えるだろうか。
Bitwarden CLI | Bitwarden Help & Support
最後に
パスワード管理、メチャクチャ大事なので気になる方は是非軽く試す気持ちで使ってみてほしい。無料なので！
技術サイト&ブログのRSSフィードまとめ
社内で技術系記事の情報の共有をしようと思い、slackに簡単に連携できるという理由でRSSを漁ってみた。
Google Reader が2013年になくなり、個人的に使ってたlivedoor Readerも2014年になくなり、RSSがほとんど抹殺されて久しいので、今どきRSSフィードなんて提供してるところはどれくらいあるのだろうか... と探してみたが、いやいや思ったよりたくさんあるもんだ。
RSS マークのボタンがなくても、 URLに /rss や /feed と入れてみると意外に配信されていたりする。
以下、探した結果をジャンルごとにまとめておく。
技術系メディアの記事
| サイト | フィード | 補足 |
|---|---|---|
| Publickey | https://www.publickey1.jp/atom.xml | 最新の技術系トレンド、ニュースに関する有益な日本語記事 |
| はてブ テクノロジーの新着エントリー | https://b.hatena.ne.jp/entrylist/it.rss | とりあえず最低限これだけ押さえておけば大丈夫感ある |
| はてブ テクノロジーの人気エントリー | https://b.hatena.ne.jp/hotentry/it.rss | 新着よりもさらに厳選できるかも（かぶりはある） |
| InfoQ | https://feed.infoq.com/jp | 最新のアーキテクチャ事例などに関する記事が毎日配信される。 |
| gihyo.jp：DEVELOPER STAGE | https://gihyo.jp/dev/feed/rss2 | 技術評論社運営。Software Designに載ってる感じの記事がたくさん |
| CodeZine(新着記事) | https://codezine.jp/rss/new/20/index.xml | 翔泳社運営。gihyoと同様だがインタビュー記事なども多く若干好みが分かれそう |
| DevelopersIO | https://dev.classmethod.jp/feed/ | ご存知クラスメソッドのブログ。AWSのサービスの検証記事といったらココ |
| Qiita Blog | https://blog.qiita.com/feed/ | サービスリリースのお知らせなどが流れるくらいかな... |
| UX MILK | https://uxmilk.jp/feed | UI/UXに関わる人は必須 |
クラウドベンダの最新情報
AWS以外もたくさんあるがとりあえず。
| サイト | フィード | 補足 |
|---|---|---|
| AWSの最新情報 | https://aws.amazon.com/jp/about-aws/whats-new/recent/feed/ | みんな大好きAWSの最新情報 |
| AWS News Blog | https://aws.amazon.com/jp/blogs/aws/feed/ | サービスリリースなどに関するブログ(jpドメインだが英語情報) |
企業の技術系ブログ
10年以上前からある、かつて憧れたWeb系企業のブログが未だ元気。見習いたい。 海外のテック企業のものももっと探してみてもいいかな。
セキュリティ情報
セキュリティ関連の情報は通常のテック系記事などと別に流れるタイムラインにフィードを流すと、話題になる脆弱性の情報などがつかみやすい。
| サイト | フィード | 説明 |
|---|---|---|
| JVN | https://jvn.jp/rss/jvn.rdf | JVN(Japan Vulnerability Notes)、脆弱性対策情報ポータルサイト。JPCERTとIPAが共同で運営 |
| IPAセキュリティセンター:重要なセキュリティ情報 | https://www.ipa.go.jp/security/rss/alert.rdf | JVNよりも後で対策などまとまった情報として出る？ |
| AWS セキュリティ速報 | https://aws.amazon.com/jp/security/security-bulletins/rss/feed/ | AWSに関連するセキュリティ情報はこちらで |
| はてブ「脆弱性」の検索結果 | http://b.hatena.ne.jp/search/text?q=%E8%84%86%E5%BC%B1%E6%80%A7&mode=rss | こんな方法もあるのか...ちょっとノイズ多い気がするが使えそう |
O'Reilly
みんな大好きオライリーの新刊情報などを通知してくれるフィード。好みによる。
| サイト | フィード | 補足 |
|---|---|---|
| 新刊・近刊情報 | https://www.oreilly.co.jp/catalog/soon.xml | めったに買わないけど流れるとテンション上がる |
| Community Blog | https://www.oreilly.co.jp/community/blog/atom.xml | 著者対談の記事など |
| O'Reilly Village/オラの村 | https://www.oreilly.co.jp/editors/atom.xml | オライリー・ジャパン編集部の雑記 |
セミナー・勉強会等イベント情報
エンジニア向けの勉強会が多いサイト2つ。どちらも興味あるグループに所属したりタグをフォローすれば関連する新着イベントのお知らせが来る。
| サイト | フィード |
|---|---|
| TECH PLAY | https://rss.techplay.jp/event/w3c-rss-format/rss.xml |
| connpass | https://connpass.com/explore/ja.atom |
参考
情報収集には以下の記事あたりを特に参考にさせていただいた。感謝。
「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ
先日から個人的にフルサイクル開発のことを色々と調べる機会があり、Qiitaに以下の記事を書いたのだが、
この中でほんの少し触れたVOYAGE GROUPの例について、情報源である「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」に書かれているその考えや文化については色々と興味深かったため、もう少し書き留めておきたい。
フルサイクル開発の文化
第2章 「Zucks - フルサイクル開発者の文化」 ではアドネットワークやDSPを提供するZucks社の開発チームの文化について書かれている。 VOYAGE GROUPのフルサイクル開発というのは主にこのZucks社の文化のことを言っている。
Zucks社のフルサイクル開発者
「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それを全て一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。お客さんに届いたものから更にビジネスアイディアが生まれ、また別のサイクルが始まります。
とのことで、開発者のみならずエンジニア全般にフルサイクルを意識して欲しいため、「フルサイクルエンジニア」とも呼んでいるとのこと。
実際にエンジニアに求められる業務範囲のイメージとしては先のQiitaの記事でも書いたが、
全部を作れる必要はないけれど、その代わりビジネス的要件を整理するところから一人でできること。
なおフルスタックである必要がないのは以下のように書かれており、
すでに動いている仕組みについては、その使い方くらいを知っていれば、ビジネスアイディアをお客さんに届けるのに十分でしょう
これだけ読むと小さい改修に限られるイメージをしてしまうが、これは逆に「ビジネス要件の整理から」という上流工程に踏み込む方がフルサイクル開発者としてより重要になるということと理解している。
このことは、Zucks社のエンジニアの求人票 に 「業務を遂行する際、大切にしている1つに、一人のエンジニアが誰かに待たされずに開発を行う点があります。誰かが仕様を決めて、それをただ実装するだけのエンジニアはチームにいません。」 と書いてあることからも見て取れる。
ちなみに、この求人票の経緯について以下のnoteに綴られているので参考まで。
ジョイン初日にリリースする
求人票にも明記されているZucksの文化として、「ジョイン初日に必ず管理画面の機能をリリースする」というものがあるらしい。 かなりインパクトがあるが、これが如何に難しいか。
なぜ難しいか
どんなに軽微なissueをアサインするとしても、ぱっと思いつくだけでも
- オンボーディング、PCセットアップから該当issueにたどり着くまでの時間の早さ
- ツールのアカウント準備やアクセス等で躓くことがない
- そもそも必ず新人が初日クリアできるような適切なissueを整理している
このあたりがクリア出来ていないと絶対に初日では終わらないから。
初日リリースを可能にしている要素
この本の中ではその他にこれを可能にしている要素として以下を挙げている。
- 基本的にmasterブランチしかない
- 広告配信は本番環境でないと分からないことが多いことなども要因と思われる
- エンジニアの権限を分けていない（全員admin権限）
- これは一見「雑」と思われそうだが...
- 切り戻しできるかどうかを重要視
- 小さな変更でも安全に戻せない（破壊的変更）のであれば止める
- DB設計もきれいさより切り戻しが容易であることが優先（カラムを消さないなど）
とは言え
新人にとってはかなり大変な文化なのは間違いない。 広告業界経験者でも初日でそこまでやるのは難しいのに、広告業界が初めての人にとっては「そもそも何を言っているのか分からない」だろうから。
しかもトレーナーになる担当者がつきっきりでもなく「何かあったら聞いてくれ」という放置っぷり。
さらに、issueの内容からして簡単な修正だと思いきや、そのissueの背景などを営業にヒアリングするなどして理解した上で適切な修正方法を取っていないとPRで総ツッコミを受けるとか、レビューしたAさんとBさんで違うこと言ってたりとかして翻弄されるとかあるらしい。
（このトークイベントの中でそんなことを言っていた）
合わない人には全く合わない文化だと思うが、新人が初日でアウトプットを出せる、事業に貢献できる実感が持てるということにはとても価値があると思う。
ドキュメントレス文化
Zucksでは、他社で通常ドキュメント化されるような情報でも、全てGithubのissueだけで管理しているとのこと。
理由は以下。
- 一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続ける作業が発生してしまう
- メンテナンスされないと新しい人が入ってきたとき、古いドキュメントを有効な情報だと思って参照してしまうことにもなる
- コードに一番近いところでドキュメント的な情報を管理しようと思ったらissueが最適だった
※ちなみに、まったくないと言っても監査目的等外部に出すために必要なドキュメント等はきちんと作っているとのこと（少し上に貼ったトークイベントの中で言っていた）。
情報が欲しいときはどうするか
- まずGithubのissueを全文検索（全員この癖をつけている）
- 探しても見つからない情報は、人に聞くか、コードを見るか
- 最終的には動いているコードが正義
- 何かドキュメントが見つかってもそれは当時のスナップショットなので基本的に「ドキュメントは更新されていない」前提
気になったこと
- 動いているコードが読みにくい、意図がわかりにくいためにまずリファクタリングから始めて複数人の認識を合わせることから始めるというケースが結構多いらしい
コードレベルでない情報もissueコメントで追う必要がある
- issueをたどって全ての議論を追う必要はどこまであるのか
- issueコメントの議論をたどると結論が変わっているケースもある
- （これはこの文化の辛い側面として触れられてはいる）
全体の俯瞰、アーキテクチャなどを伝えるのは都度ホワイトボードに集まって説明するなどでカバー
- これは面倒くさくないのか... オンボーディングのコストがめっちゃ高い気がする。。
- これがあるのに初日リリース出来ているのには矛盾すら感じる。
このあたりを見ると特に新人向けにはお互いの伝達コストが高い気しかしないので、正直いってあまり納得感はなかった。 とは言え、だいたいどこの現場でも経緯が分からんというケースの方が圧倒的に多い気がするので、それを考えるとこう振り切ることのメリットの方が大きい、ということだと思う。
なお、新人向けにシステムのことを理解してもらう際には、まずは管理画面を一回触ってもらうことで流れと項目が理解できるので、それとセットで動いているコードを説明するなどして全体像理解のスタート地点に立ってもらうとのこと。これは理解できる。
その他印象に残ったところ
SRE部門の解散の背景
（第1章 「fluct - 広告配信の舞台裏の技術者たち」より）
SSPを運用するfluct社で、2019年11月にもともとあったSRE部門を解散し開発部門に統合。その背景としてこんな理由があった。
- だんだん開発チームからSREチームに「依頼」するケースが増えていた
- DevとOpsが分かれていることは悪くないが、本来は同じ目的を共有するチーム間で「依頼」が発生するのは本意ではない
ビジネスと一緒に開発する
（第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より）
就活支援サービスを展開するサポーターズ社では「ビジネス側から言われたものをそのまま作ることはしない」姿勢を明言している。
- かつては社内受託のような形で「この画面をこういうふうに作ってください」という、アウトプットが規定された「依頼」が普通だった
- 今はそのような来た場合は「なんで？」と即座に返す
- 「なぜ」を聞いた上で当初の提案よりもコストのかかる実装（理想）を提案することもある
- 今すぐ結果だけ欲しい人にとっては「いまはそれは良いから、すぐにできることだけ話してくれ」と感じる
- 「ちょっとしたお願いを相談しただけなのに、なんでこんな大きな話にされて、いっぱい話さないといけないんだろう」
これは非常に「べき論」を地で行っているが、ビジネスの方が立場の強い会社だと開発側が負けてしまうし、開発側が強い場合はビジネス側が「開発は相談に乗ってくれない」と不満を漏らして二度と相談に来ないという結果を生みやすいので、如何に日々コミュニケーションを濃密に取ってお互いを理解しているかというのが伺えるエピソードだった。
ちなみに、このような相談の場合にケンカにならないために押さえておくべきポイントを言うなら、
- ビジネス側：背景をきちんと伝える、結果を急ぎすぎない（サクッと明日までに大体で良いから見積ほしい（でも上振れしないでねという圧）とか）
- 開発側：温度感を踏まえて聞く、むやみに話を大きくしない（エンジニアは「そもそも〜」で話を振り出しに戻して大きくする人が多い）
以上踏まえてお互いに落とし所を見つけることかなぁ、と自分の肌感覚では思っている。
依存ライブラリは週1で上げる
（第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より）
同じくサポーターズ社で、「ガーデニング」と称してフロントエンドやサーバーサイドの依存ライブラリを毎週最新化するという運用を行っているとのこと。
- 最新バージョンへの追随は一度やめると二度と復活できないので、1ヶ月ではなく1週間で実施
- 「ガーデニングガチャ」で当たった人が実施
- 週次で上げるのはマイナーな変更（既存コードの変更がないもの）のみ
- ライブラリを上げる作業自体はコード変更がなければ単純作業なので、ガーデニング作業そのものの大半はchangelogの確認
これは簡単そうにやっているようだが、実はすごいこと。そんなこまめに上げていたことないな...
最初の1,2回なんとか乗り越えれば、後はそれほど苦ではないのかな。
でもメジャーバージョンアップがあるとこのルーティーンとは別タスクでやらないといけないはずだから、そこは同じなのかな。
最後に
2章のことでたくさん書いてしまったため他の章の取り上げ方が雑になってしまったが、 他にもレガシーのシステムといかに付き合っていくか、改修とリプレースの判断はどうやって行うのか、など、外から見ると楽しそうにやっているWeb系企業の現場で直面する決して華やかではない、むしろ泥臭さしかない課題に対する取り組み方などについても臨場感の伝わる記述がされたとても熱量の多い一冊だった。開発現場を経験しているエンジニアならきっとよくうなずく箇所や「いやこれはちょっと...」と賛否両論の独り言になること請け合いなので、是非一度手にとって頂きたい。
MacVim、Atomのvim-modeでEsc時にIMEをOFFにする方法
やり方を忘れてしまい新しいPCSierraでどうすんだっけ、と思い調べると、殆どが Karabinerによる設定方法ばかり。 最近Karabiner-Elementで対応できる様になったというのも見たのでいいんだけど、できればKarabiner無しでどうにかなんないかなぁと思ってたら、
Google日本語入力の設定だけでできるじゃん！
とっても助かりました。
このスケジュールで問題ないですか？
英文でスケジュール打診をするメールを書いているときに
「来週●月●●日以降に始めたいんだけど、問題ない？」と書こうとして、
”問題ない？”の部分をどう書こうかなぁ・・・と思い調べてみたところ、 ちょうどよいフレーズが紹介されていた。
うまくハマった（気がする）のでメモ。
Is there any way that you can adjust to this schedule?
（この予定に合わせて頂く事は可能ですか？）
このサイト、他にも使えそうな気になるフレーズが紹介されている気がするのでちょいちょい見てみよう。
