Hnoss

Hnoss

GitLabのグループ機能はとんでもないツールだった。
カレンダー

文書タグ

フノス(訳者)(208) IT(184) 解説記事(140) マニュアル(78) GitLab CI(58) オープンソース(50) Linux(38) GitLab(33) メディア(33) コンテナ(28) ウェブ制作(25) DTM(19) HTML5(19) Libre Music(18) おすすめ オープンソース・ソフトウェア(18) 百科事典(14) プラグイン(13) 文化(12) ソフトウェア(11) セキュリティ(11) 録音(11) ミキシング(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) コマンド(8) シーケンス(8) 芸能(8) 音楽編集(8) 音楽(7) 経済(7) マスタリング(7) Raspberry Pi(6) 業務効率化(6) マイクロサービス(5) Google(5) WordPress(5) アプリ(5) JACK(5) Ubuntu(4) 北米(4) Windows(4) Android(4) ワークフロー(4) 映像制作(4) ハンドブック(4) GNU(4) 欧州(4) 音楽プレーヤー(4) Python(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Java(3) ソーシャルメディア(3) DAW(3) 法律(3) ロスレス音源(2) BountySource(2) スマホ(2) 牛(2) 歴史(2) ニュース(2) GNOME3(2) iOS(2) PlayStation(2) 仮想通貨(2) 古代エジプト(2) マーケティング(2) 有角神(2) エジプト(2) ALSA(2) OS X(2) ERPシステム(2) 電子ブック(2) トヨタ(2) バト(2) Krita(2) 電子書籍(2) ウィッカ(2) GPL(2) ERP(2) オカルト(2) Twitter(2) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 日記(1) 聖書(1) 任天堂 DS(1) 教育(1) bi-modal IT(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) Papagayo(1) 写真(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) ヤーウェ(1) CD(1) タブレット(1) 学校(1) 日本(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) アップストリーム・パッケージング(1) 画像(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) サウンドフォント(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) ポータブルソフトウェア(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) クヌム(1) 魔女裁判(1) オンデマンド(1) リーナス・トーバルズ(1) バフォメット(1) UNIX(1) 黙示録(1) スタジオジブリ(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) 政治(1) イボ人(1) 国際(1) クリエイティブ・コモンズ(1) amazon(1) キリスト教(1) レビ記(1) Synfig(1) 独占(1) アマナイ(1) 広告(1) KXStudio(1) EU(1) イケンガ(1) 国際公文書館会議(1) マイナビ(1) 募金(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) 出エジプト記(1) 観光案内(1) 絵文字(1) サンフランシスコ(1) パキスタン(1) リクルート(1) ハトホル(1) パン(1) 地方(1) Blender(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ツイッター(1) Youtube(1) 中南米(1) モヘンジョ=ダロ(1) CC(1) 声明(1) 悪魔(1) ラジオ(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) ゲーム(1) パシュパティ(1) 1Password(1) アピス(1) 宗教(1) テレビ(1) OpenToonz(1) 電子教材(1) 船乗りの柱(1) シリア(1) GPS(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional


現在の位置:チームハンドブック 目次>推奨セキュリティ対策

 セキュリティ関連項目

 推奨対策


1.1Password」というソフトウェアを、社員のパスワード管理システムとして導入する。そして、強固で独自性の高いパスワードを設定しろ。

  • マスターパスワードは絶対に秘密だ。同じチームにいる人にも、それが管理者であったとしても、察せられてはならない。マスターパスワードが、他人に知られたり、開示されてしまった場合は、直ちに変更しろ。
  • マスターパスワードを忘れてしまった場合は、「#PeopleOps」にメッセージを投稿しろ。
  • マスターパスワードには、機械で生成されたランダムなものをおすすめする。しょせん人間が考え付くパスワードなどは、他の誰かもすぐに思いつくものだ。
  • 強固なマスターパスワードは、「1Password」で作成できる。ただし、生成されたマスターパスワードについては、自分で暗記しなくてはならない。
  • 他のパスワードマネージャーにマスターパスワードを入れるな。容易に不正ログインのもとになり得る。
  • 詳しい操作法は、こちらのGetting Started guideと、サインアップの過程を説明したこちらのビデオガイドを参考にしてほしい。
  • アカウント管理者については、こちらのadmin guideを参照すること。

2.パスワードを使いまわさない。会社のアカウントや、GitLab以外に個人的に加入しているサービスのパスワードを使用するな。

3.「1Password」を使い始めたら、これから作成するアカウントのパスワードは、全てこれに管理させろ。あとはソフトウェアが適切なパスワードを設定してくれる。

4.加入する際に、サインアップを求められるサービスについては、日頃からアクセスを共にしているチームメンバーのことを第一に考えて、慎重に考えろ。この手のサービスには、3つの認証形態がある。個別方式(Individual)、OAuth方式、シングルサインオン方式である。IndividualとOauth方式のアカウントサービスについては、チーム共同のセキュアノートを設けるとよい。このノートには、プロジェクトの管理者が日頃どのようなサービスにアクセスしているかを報告する。ここには基本的に、チームメンバーが関連している全ての個別認証サービスを記述することが求められる。

  1. 個別認証サービス(Individualとも。手動で各個人が作成するアカウント。Googleアカウントなどが有名):あなた個人を指すアカウントについては、GitLabチームアカウントで管理している『1Passwordセキュアノート』の、’Personal[個人]’という項目に記録する。
  2. OAuth サービス(GitLab や Googleアカウントを介した認証方式をとっている。grafanaなどのサービスが有名。)
  3. シングルサインオン サービス(個別認証アカウントを必要としないサービス。企業向け有料サービスによくある。):「1Password」のように、企業や団体・チーム単位で設けられる認証方式とっている。この場合アカウントはグループ全体として処理されるので、個人での認証が必要ない。

5.二元認証をユーザーに義務付けろ。ログインの際にリカバリーコードを設けるようにする。そして1Passwordの TOTPコードを使え。

6.信任状は必要に応じて、チームのメンバーがアクセス可能な場所に移しておくとよい。信任状は決して複製したり、出力してはならない。そのかわり、チームの信任状を、社員全体がアクセスできるように、「1Password 共有フォルダ」をグーグルシートに作成しておくことをおすすめする。各個人に与えられ、「1Password」で一括管理されているパスワードを、決して公開・シェアしてはならない。これは信用を守るために、重要な責務である。

7.「1Passwprd」内で保管されているパスワードをコピーするな。同様に、コピーしたパスワードを個人的なパスワードとして流用したり、他のパスワード管理ソフトに貼り付けることを禁ずる。「1Password」にて管理するパスワードは、あくまでチームのパスワードを管理するために使うべし。開発チームで用いるパスワードは、どこかにコピーするべきではない。まして、個人のパスワードとして転用することは、それだけパスワード流出の確立が高まるということだ。

8.合言葉として使われる質問(『好きな食べ物は?』など)には、本当のことを書いてはいけない。そんなことは容易に調べがついてしまう。チーム内でどのような質問を作り、回答を作ったかについては、「1Password」に記録しておけ。なおかつ、回答はでたらめであるほどよいので、ここで「1Password」のパスワード生成機能を使うと、なおよろしい。

9.信用証明書をemailやイシューコメント、あるいはチャットなどで公開・共有してはいけない。証明書には、ログインやAPIキーとして使われるEmailアドレスが記されている。こういうものには、「1Password」の資格情報コンテナーを使え。会社組織に所属した人間には、そこに招待することによって、証明書を見せることができる。

10.自分のパスワード管理フォルダを見たくなったり、新しい場所が欲しくなった場合は、Google Docの「1Password Shared Folders」に一言報告を入れろ。パスワード管理コンテナにアクセスできるグループを追加したり、それぞれのコンテナにディレクトリを加えることもできる。アクセスを許可したグループが、自分たちのグループに相応しいと考えた時には、我々の側に所属させるとよい。数百人分ものアクセス設定をそれぞれの個別にやっていくよりも、12~3個くらいのグループで管理させた方がはるかに効率的だ。

11.「1Password」の管理者は、リクエストを受け付けることができる。:(グループにパスワードコンテナにアクセスさせる代わりに)資格情報コンテナを個別に設けると、このとき、メンバーの権限はある程度抑制されているので、彼らが「出力可能なアイテム」としては扱われない。この方法は、デフォルトでは取られないようになっているので、管理者の手動設定が必要だ。ただし、グループに入っただけの人間が、簡単に弄れてしまうような部分を、こんな大切なところに設ける必要性は低い。やはり単なるアクセス権を与えることの方が、安全性は高い。

12.任意の情報コンテナが探しても見つからない場合は、状況説明をグーグルシート「1Password 共有フォルダ」の適当なセルに記述しろ。

13.アイテムの状態をという合わせるには、「VAULT_NAME」というコンテナの、「NAME_OF_SITE」という証明書を確認する旨を伝えろ。
  たとえば、「for access please see the AOL credentials in the Luddite vault」
    (Ludditeコンテナに入っている、AOL証明書を確認するには)という風に。

14.パスワードをウェブブラウザ(Chrome や Safari)に保管するな。「1Password」だけでパスワードを管理することを念頭にしているので、こういった行為は思わぬリスクを呼ぶし、何かあったときに原因究明に時間がかかる。

15.変更が必要となったパスワードは、「Watchtower」という機能を使って検出しろ。
 この機能は、チーム用の「1Password」内で保管しているパスワードに、異常事態が発生していることを知らせてくれる。パスワードが破られたり、パスワードを使っているウェブサイト側にセキュリティ事案が発生した場合などに、通知がある。対処するかどうかは、ユーザーにゆだねられる。
 この通知は、あくまでユーザー個人に送られるものであって、アカウント管理者が見ることができない。各自でチェックするしかないのだ。
 各自1Passwordアプリを開いて、「Preferences > Watchtower」に移動するべし。

16.Security Audit(セキュリティ評価)」機能を使うと、使いまわしているパスワードや、弱いパスワードなどを検出して、修正することができる。

17.1Password TOTP を使うことで、GoogleSlackGitLab.com、またはdev.gitlab.orgアカウントに、2元認証(2FA)を設けられる。

18.旅行・出張の際には、1Passwordを「Travel Mode(トラベルモード)」にして出かけるとよい。詳しくは後で説明する。

19.GitLabの認証では、Yubikeyも併用することを推奨する。

20.作業に使うコンピューターと電話は、全ディスク暗号化しろ。
 Mac を使っているのなら、FileVault(詳しくはAppleサポートを参照) あたりを使うとよい。
 GNU/Linux を使っているのなら、LUKS(Arch Linux Wikiにおおよその情報が書いてある。)らへんを使うだろう。

 ラップトップのフタを閉じて、RAMが動きを中断している間は、ハードディスクを守る手段が、暗号化していること以外にない。
 (サスペンドではなく)コンピューターの電源を完全に落としているときには、誰かが手作業で、機械から記憶媒体だけを抜き盗る可能性を考えた方がよい。

 と、いうのも、入国審査時の税関などで、案外そういうことがあるからだ。

 この対策は、記憶媒体を書き換えるタイプの攻撃(memory-based attacks)の被害を抑制するのにも効果的だ。詳しくは、こちらのページをご覧いただきたい。

21.お前のラップトップのスクリーンセーバーには、パスワードロックをつけろ。時間が来たら、ラップトップを誰かにいじられづらくした方が良い。

22.コンピューターに何のロックも仕掛けないまま、席を立たないこと。ロック付きのスクリーンセーバーに切り替えたり、デスクトップをロックしてしまうとか、フタを閉じるとか、応急的なことくらいはしておけ。

23.コンピューターのバックアップを取ったら、そのバックアップ・ドライブごと暗号化し、強固なパスワードを設けよ。

24.macOS (OSX) のバックアップの取り方については、こちらの説明が詳しい:How to use Time Machine

25.社内があまりにおかしな事態に直面したら、そのことを実況するか、パニックボタン(後述)を使うとよい。

26.セキュリティ上の話題について提議する際には、セキュリティ・イシュートラッカーにイシューを提出しろ。対応をセキュリティチームに依頼するのだ。事案に対する最良の対処・処理を、チーム招集会議で議論すべし。

27.どのような方法(イシュー、カスタマーチケット、その他)であれ、部署であれ、セキュリティについての報告を受け取ったら、決して、放置したり、なかったことにしてはならない。必ずセキュリティ・チームに相談しろ。セキュリティ・チームは、チームのハンドブックに書いてある作業手順に従って、然るべき対処を下せ。

28.組織のEmailアドレス(@gitlab.com) を使って、社外のEmailアドレスに、メールを送信してはならない。

29.Emailに貼ってあるリンクをクリックするな。
 身に覚えのないメールについては特に警戒せよ。(『パスワードの変更が必要だ(→1Password管理なら、メールで通知が来るのはおかしい)』など、危機感を煽る内容なことも多い。)
 ただし、例外がある。GitLabの様々なサービスを使うために、アカウントを登録する際に、登録用Emailが送られることがある。このような場面では、リンクをクリックする前に、管理している人物と直接連絡を取れ。「プロセスを初期化した?」などと、きちんと確認ができないかぎりは、絶対にクリックするな。
 不審なリンクをクリックしたら、自分のパスワードを入力していないにも関わらず、システムが壊されることが多い。なぜなら、その時にはすでにゼロデイ攻撃の準備が整ってしまっているからだ。
  我々としては、外部サービスを装って、わが社のアドレスに送られてきたメールから、フィッシング攻撃がされることを想定して、社内全員にその恐ろしさを周知している。

30.個人的にもおかしなメールが届いたり、セキュリティ面で気になることが起こったら、すぐさま社内のセキュリティ担当に相談を仰げ。もうすでに会社に攻撃が来た時の備えが必要だ。社員の話に重要な手がかりが入っている可能性がある。

31.GitLabのCEOは、Emailを使ってお金を請求することがない。CEOが金銭を要求したり、業務には直接関係しないことを無理強いしてきた場合は、すぐさまテレビ電話をつないでくれ。

32.ログインしてまでサービスを使うのは、信用の置けるデバイスを使っているときだけにしろ。公共施設に置いてあるコンピューターなどは、何が仕掛けてあるかわからないし、そもそも相当無防備な状態で放られている可能性が高い。自分のコンピューターを持つことだ。
 我々チームのメンバーなら、自分のアカウントにサインインするのは、決まったコンピューターからのみにするべきだ。

33.開発チームを脱退するときには、お前の「1Password」のアカウントを処分する。それと同時にGitLabチームアカウントにあてがわれた情報コンテナ(Personal vault)も削除される。
 GitLabチームアカウントを所持する前に、個人で1Passwordにサインアップしておいたアカウントがあるはずだ。引き継ぎたいパスワードがあるのなら、そこの「Primary vault」という情報コンテナに、必要なパスワードをコピーして動かしてしまうことをおすすめする。

34.わが社の「1Password」で管理しているパスワードは、定期的に変更したりはしないように設定してある。 

35.セキュリティの脆弱性が明らかに多すぎるソフトウェアは、インストールするな。(ハンドブックにリストがあるので参考に。)怪しい点があるソフトウェアについては、まずイシューを出してチームで議論・審査してからインストールの是非を決定しろ。出した結論やその理由については、ハンドブックに記述すること。

 「1Password」ガイド

 「1Password」とは、パスワードマネージャーだ。どこのサービスも、「強いパスワードを作って暗記せよ」と口先では言ってくれるものの、現実的ではない。そこで、このパスワードマネージャーが、外部からばれづらいパスワードを作成・管理する。どのパスワードも類似点ができないように設計されており、ログイン毎に違うパスワードが使える点が安心である。

 用語解説

 以下のガイドでは、主に次の用語を使っていく。

  • App(アップ): コンピューター(OSX, iOS, Windows, Android)に、直にインストールした「1Password」アプリケーションのこと。
  • Extension(エクステンション): ウェブブラウザの拡張機能/プラグインのこと。Appと連動してパスワードを管理する。ブラウジングを中断せずに、安全なパスワード利用を実現する。
  • Vault(ヴォルト): 厳重に保管しなくてはならないデータを収容する部分。ログインに関する情報やセキュア・ノートなどは、ここに保存される。「1Password」独特の名称のため、先ほどの説明では、”情報コンテナ”などと記載していた。「キーチェイン」と呼ばれる場面もある。

 1Password

 「1Password」には、2通りの使い方がある。
 まず1つ目は、単に独立したアプリケーションとして使う方法。(利用者が「standalone license」を購入する。)
 2つ目が、ホストサービス(定期購入制)である。

 GitLabの場合は、「1Passwords for Teams」というホストサービスを使っている。

 「1Password」をGitLabで働いているときだけでなく、個人的にも使いたいという方には、いくつかのオプションがある。(後述)

 1Password for Teams

 「1Password for Teams」は1Password サーバー上にある、全てのvault(ヴォルト)を、「同じチーム同士の人間」というくくりで複数人と共有するサービスだ。

 GitLabに所属している人物なら、すでに我々のチームアカウントにサインアップを果たしているはずだ。ウェブインターフェイスから、それぞれにあてがわれたvault(ヴォルト)にアクセスして、内容を確認してみるとよい。

 チームでパスワードの内訳を共有する「Team vault」。さらに、チームの各メンバーには「Personal」と呼ばれる、他のユーザーが閲覧できないvaultが用意されている。このvaultもチームのアカウントに所属しているには違いないが、ここに個人のパスワードを入れるとよい。
 Googleドライブで保管されている「1Password Shared Folders」というシートには、現在開発プロジェクトで利用されているvaultsと、どのグループやメンバーがどのようなサービスに接続しているかが把握できるようになっている。
 vaultに登録されていない先にアクセスするには、このシートにその行き先を登録しなくてはならない。シートに説明文を記述し、1Password管理者にメッセージを送付する必要がある。1人でよいから、管理者の誰かから許可をもらえ。1Password の管理者は、1Password内チームヴォルトのセキュア・ノートに一覧があるので、そこから探すこと。

 1Passwordの大まかな使い方がわかったところで、次はチームのアカウントとネイティブappとを関連付けるところから始めよう。

 1Password app に GitLabチームを追加する

 このガイドでは、OSX用 appでセッティングする方法を説明していく。推奨とされるプラットフォームは、公式サイトで提示されている最新版である。この説明は、Windows版appでも応用できる部分があるかもしれない。

  1. 1Password OSX用 appを、ダウンロードして、インストールする
  2. appを起動する
  3. 「Sign in to your 1Password account」をクリックする。仮にそのボタンがなかった場合は、本文の後で説明する方法を参考に、1Passwordをアップデートする。

 チームアカウントに登録する際に、1passwardから「緊急対策用PDF(Emergency Kit PDF)」が渡される。これをどこかに保存しておく必要がある。Emergency Kit は、なるべく確実に保管しなくてはならない。Emergency Kit のコピーをUSBフラッシュドライブに移したり、紙に印刷して自宅のどこかに保管する。少なくとも、オンラインではなく、他の誰かがアクセス可能なところでないことが重要だ。

 デジタルなPDFファイルを保存するには:

  1. PDFファイルを開く
  2. 「Scan QR Code」をクリック
  3. PDFシート上のQRコードをスキャナー・ウィンドウにドラッグする

 PDFを印刷するには:

  1. Sign In Manually」をクリック
  2. Team URL」の部分に「gitlab.1password.com」と入力する
  3. Account Key」の部分には Emergency Kit に記載されているアカウントキーを入力する
  4. Email Address」には、自分の「@gitlab.com」がついているemailアドレスを書き込むこと
  5. チームアカウントのパスワードを「Master Password」の欄に入力する。(その上にある『I'm a new user』ボタンを押さない。チームとして認証されなくなる。)

 チームに加わったら、1Passwordヴォルトについての説明書きを、きちんと見ること。デフォルトでは、各メンバーは「Team」と「Personal」のヴォルトに出入りができる。だが、業務の関係上、その他のヴォルトにもアクセスすることになるだろう。

 チーム機能が見当たらなかった場合は、1Passwordをアップデートする

 前章「1Password app に GitLabチームを追加する」にて、
 「『Sign in to your 1Password account』ボタンが見当たらない」場合があることについて、少し取り上げた。
 この章は、それに当てはまってしまった人だけに読んで欲しい。

  1. 先ほど、「『I'm a new user』ボタンを押してはならない」と紹介したが、この時だけは例外だ。かえって押せ。「チームアカウントに所属したいだけなのに、どうしてもう1度作り直せとか言っているの?」と気になるだろうけれども。そのまま進んでいけ。
  2. ここで「チームアカウントのマスターパスワードを入力する」という操作が要となる。ここで入力するパスワードは、お前が所属しているチームアカウントで使われている物でなくても構わない。その代わり、そのパスワードを使用して、ローカル環境(コンピューターやスマホ)のプライベート・ヴォルトが開通する。
  3. この後に続くダイアログ(同期について、ニュースレターがどうの、など。)を過ぎたら、
  4. 空白のヴォルトが出来上がる。これをPrimaryヴォルトという。

 お前が現在所持している「1Password」のバージョンでは、チーム機能に対応していないというのだから、この際にappを最新版にアップデートしてしまえ。

  1. 1Passwordの「Preferences」に移動
  2. Updates」に移動
  3. Check Now」をクリック
  4. アップデートをインストールして、再起動
  5. 再起動したら、再び「Preference」に移動
  6. Accounts」に移動
  7. + アイコンをクリック


 Vaults(ヴォルト管理)

ウィンドウ左上の角に、「Vault Selector」というコーナーがある。

 (写真1)Vault Selector

Teamヴォルトは、GitLabチームのアカウントに登録されている人物なら誰でもアクセスすることができ、閲覧と編集が可能だ。

Personalヴォルトは、自分でホストしているプライベートヴォルトのことである。このヴォルトはGitLabの 1Passwordアカウントの一部として扱われている。「Personal」と言われても、このヴォルトはGitLabチームアカウントの一端として処理されるので、あくまで「GitLab社の持ち物」という分類だ。これは「@gitlab.com」で終わるEmailアドレスと同様だ。しかし、このヴォルトは、これを使っているメンバー個人以外から覗き見られないようになっている。なので、同じチームに在籍しているメンバーや、GitLab社のアカウントを管理している人物でさえ、各個人のPersonalヴォルトを見ることはできない。
 ただ、1つ注意しておきたい。このPersonalヴォルトに、本当に私用の情報を保管することはおすすめできない。というのも、GitLab開発から脱退すると、そのメンバーのPersonalヴォルトは他のメンバーに公開されてしまうからだ。
 GitLabチームアカウントとはまた別に、個人専用の1Passwordアカウントを作成しておけ。(方法は後述) 個人の趣味アカウントなどについては、各自のアカウントのPrimaryヴォルトに保管したほうが良いだろう。

 ブラウザ拡張機能

 各ブラウザの拡張機能に移動して、「1Password」のエクステンションをインストールするとよい。ここでインストールするのは、ベータ版ではない方が良い。

 ブラウザ拡張機能をインストールできたら、我々の開発チームの証明書が保管されているサイトに行ってみろ。ログインができるはずだ。

 (GIF1)MailChimp にログインしてみる

 結果ウィンドウのリスト内に、その証明書サイトが出現しなかったら、正しいヴォルトを使えている証拠である。

 (GIF2)ヴォルトの切り替え

 ログインを保存する

 1Passwordがログインフォームを検出すると、つぎのようなダイアログが表示される。

 (写真2)ログイン保存ダイアログ

 保存する場合は、最初の欄から当てはまるヴォルト(Vault)を選択することだ。

 複数アカウントと、appのロック解除について

 これについては一度、 1Password FAQをご覧いただきたい。

 GitLabチームの1Passwordアカウントと、自分個人の1Passwordを使い分けたいときに、まずはappでアカウント設定を実施する必要がある。「Preferences > Accounts」に移動しよう。次に、1Password appを私用アカウントのマスターパスワードで解除する。

 GitLabチームに属する前に、既に1Passwordを使っていたという人は、「Migrate To Account」から「I'll move later」を選択しよう。この方法なら、vaultsの共有が簡単で、アイテムの引き継ぎに困らない。

 私用パスワードの保管

 個人的な用で使うパスワードについては、GitLabで働くときのアカウントではなく、きちんと個人のアカウントを使用することをおすすめしていた。その方がセキュリティ上の問題が少なくなりそうだからだ。
 私用のために、もう1つライセンスを購入するか、定期購入を開始してもよいだろう。
 確かに、GitLabチームに登録していれば、「Personal」ヴォルトを獲得することはできる。これならライセンス購入と同じ機能が使えるし、お金がかからない。だがチーム脱退後に、そこに保管していたパスワードが、全て公開されてしまうという難点がある。

 ここはどうか、そんなつまらないところでけちらずに、ライセンスを購入するか、完全私的なローカルヴォルトを作成するかして、皆さんのデータを自分のコンピューターで保管してほしい。
 ヴォルトが入ったフォルダは、同期クラウドをDropbox か iCloud (Mac/iOSを使っている場合)から選択できる。これらのサービスと連携して、スマホの1Password appや、他のコンピューターでの情報交換が容易になる。

 AgileBits(1Password運営)が紹介しているところによると、1Passwordにサインアップしてから次のような手順を踏むとよいらしい。

 個人でローカルヴォルトを作る方法:

  1. Preferences」に移動
  2. Advanced」に移動
  3. Local Vaults」から、「Allow creation of vaults outside of 1Password accounts」にチェックを入れる
  4. マスターパスワードを入力
  5. 新しいローカル・ヴォルト(プライマリーヴォルトとも)が、GitLabチームアカウントの外側に作られる
  6. このローカルヴォルトに同期機能をつけたい場合は、「Preferences > Sync」から設定すること


 2元認証と、時間ベースのワンタイム パスワード

 2元認証(2FA)コードを1Passwordで利用するには、いくつかの方法が存在する。
 たとえば、2つ目の鍵をSMSなどを介して送信する方法だ。これはGoogle Authenticatorなどでとられている。
 1Password でも、このタイプの2元認証に対応しているが、時間ベースのワンタイム パスワード (TOTP)である。つまり、必ずしもスマートフォンが要るわけではない方式だ。2FAの合言葉は、1Password app を動かしているラップトップの画面に直接表示される。

 このアプリに保存しているアカウントに、TOTPを導入する方法:

  1. 1Password appを開く
  2. TOTPを設定したいアイテムを選択する
  3. 右下の角にある「Edit」をクリックする
  4. 横並びに3つの点が描かれているアイコンをクリックする
     (写真3)3点アイコン
  5. One-Time Password」を選択
  6. QRコード柄のアイコンが出現するので、それをクリックする
  7. 透明窓を使ってQRコードをスキャンする
  8. Save」をクリックする
  9. 次回から、設定先でログインを試みると、2FAコードが表示されるようになる。

 TOTPの詳しい使い方や、仕様については公式ブログで紹介されている。

 QRコードの読み取りに「透明窓」を使うというのは、最近のMac OSではできない操作らしい。代わりに1Password iOS appを使うとよい。QRコードの読み取りができる上に、Touch ID(指紋認証)ログインにも対応している。

 1Password 使用例

 ここでは我が開発メンバーである、ロバートの1Password使用例を紹介する。

 自分が利用するセキュリティ情報は、全部1Password で管理してしまった方が良いと思うんだ。こういうことは人間には向かない。機械に任せてしまった方が、自分の生活の質が幾分か上がったような気がするよ。

 覚えるパスワードは1個だけ。これをかなり分かりづらいものにしておけばよくて、他のパスワードについてはアプリがどうにかしてくれる。どのサイトにも、自分では覚え切れないくらい沢山の独自パスワードを使うことができるようになる。「使いまわし」というものがありえない。1つのパスワードを知られて、他のアカウントまで乗っ取られる心配は大幅に減る。

 宅配やクレジットカードの情報も1Password に入れてしまった。ネットで買い物をする時に、配達と支払いの面倒な記入があるじゃん。あれ、ブラウザの拡張機能を使えば、物の数秒で終わってしまう。

 他のデジタルスキャンと一緒に、パスポートのデータも入れた。免許証とその控えの情報、保険、ソフトウェア・ライセンスキーだどか、必要な時にさっと出さなくちゃならないことを、安全に保管して、どこからでも引き出すには、この方法が簡単だ。
 Personalヴォルトは、自分のDropboxと同期するようにしているから、スマホ、タブレット、ノートパソコン、デスクトップからアクセスできる。

 GitLabのチームアカウントに関連する情報は、自分のPrimaryヴォルトに入れている。そこにはEmergency Kit PDFも一緒に入っているよ。

 (写真4)チームにログイン

 パスワードについてこれ以上有効な策はないね。というか、ずっとこういうのが欲しかったんだ。それがやっと世に出てくれたって感じ。


 トラベルモード

 旅行・出張などに行く際には、普段からGitLabの1Passwordヴォルトにアクセスするときに使っている1Passwordをトラベルモードに設定すべし。
 トラベルモードとは、1Password appに存在していた全ヴォルトのコピーを、一時的にデバイスから削除する機能である。ただし、これはモバイル デバイスから「safe for travel」タグを付けたヴォルトには適用されない。
 GitLab開発チームに関係する(仕事メインの)ヴォルトには、「safe for travel」タグをつけることはできない。
 旅先でヴォルトを使おうと思ったら、私用ヴォルトには「safe for travel」タグをつけた方が良いだろう。また、旅行用ヴォルトを専用に作っておいて、そこに出張などで利用するパスワードを保管するという手もある。

 ほぼすべてのヴォルトが削除されることで、旅行中は専用タグが付いているヴォルト以外は使用不可能になる。
 Travel Modeを有効にすると、他のデバイスにインストールされている1Passwordでも、そのモードが適用される。1Password.comの同期機能は、こういうところで発揮されるのだ。

 Travel Mode の詳しい使い方については、AgileBits blogを参考にしてほしい。

 セキュリティ警戒度テストの実施

 GitLab社では2週に1回、社員のセキュリティ警戒度を測る目的で、リンクが仕掛けてあるEmailを送付している。フィッシング攻撃を見分ける練習と、公共無線ネットワークの安全な使い方、その他セキュリティ知識、ヒント、行動原則などの確認を呼びかけている。

 フィッシング・テスト

 GitLabでは、サードパーティープラットフォームを使って、定期的にフィッシングテストを実施している。チームのメンバー全員に対して、一風普通のメールが送られてくる。ぱっと見た感じ、「ビジネス関連の連絡」といったところだが、これが罠だ。実際に起こったフィッシング事例を基にしているので、「こういうものがやって来る」という参考になるだろう。
 現実のフィッシング攻撃は、信用証明書を偽装したり、関係者をだましてウイルスをダウンロードさせたり、攻撃の手はずを整えさせたりする。
 もちろん、GitLabが送信する偽メールや、サードパーティーテストを作っているサイトでは、証明書の偽装や悪質なコードを送付することはない。

 これらのサイトが目的としていることは、誰しもが凶悪なリンクをクリックしないようになることと、これらの攻撃犯を罰することにある。しかし、まずは一般のユーザーたちにセキュリティに対する意識を持ってもらうことと、攻撃犯から身を守るテクニックを身につけてもらうことを目標としている。その中でも、Emailを使って誰かを欺き、悪意のあるソフトウェアを実行させ、ウェブパスワードを乗っ取る攻撃が典型的だ。
 もしお前が、訓練メールに引っ掛かったら、もう一度トレーニングコースをおさらいするか、セキュリティチームに「自分でもできる対策」「いろんな人が意外としていない対策」について問い合わせてほしい。
 度々訓練を受けているにもかかわらず、攻撃に引っ掛かってしまったときには、かえって報告を入れろ。セキュリティチームは情報協力がないと始まらないところがある。自分を恥じたりしないで、一体どういうところで騙されたのかについて教えてほしい。
 オンラインでこれ程失敗が起こりやすいことは、「インターネットは先進的である」という思い違いから産まれているのだ。

 フィッシング攻撃の見分け方(基礎)

 Emailについていたリンクを慌てて押してしまうのが良くない。まずは、リンクの上にマウスカーソルをそっと重ねてみろ。
 すると、なんだかメールに書いてあるURLと、全然違うURLが、画面の左下に表示されていないか?まずこうなると怪しい。

 それでも誤ってクリックしてしまうことが怖い場合は、ブラウザを使ってリンクを確認するとよい。
 Google Chromeの場合は、リンクが本当はどこにつながっているかを、ブラウザウィンドウの左下角に表示してくれる。

 (写真5)Google Chromeのホーバー

  Safariでリンク先を確認する場合は、ステータスバーを有効にする必要がある。「View -> Show Status Bar」に移動して設定しよう。

 ここでURLが途中で見切れてしまっている場合は要注意だ。
 URLの最初だけ同じに見せかけて、最後の方に行くとアドレスが違うことがある。これは偽の入力フォームに移動させて、大切なデータをユーザ自らが入力するように仕向ける罠であることが多い。

  • HTTP(S) とホスト名は同じなくせに、実は有害サイトに誘導しようとしている例。末尾の方になると、URLがおかしい。
     (写真6)危ないドメイン
  • ユーザー名やパスワードを尋ねるページのURL。ドメインとかは信用のおける会社のもの。ところが、よく見ると途中から別のサイトを見るためのURLになっている。こうも長いURLだと、簡易のビューアでは気づきづらい。
     (写真7)だまし目的があるURL
  • HTTP(S)ではなく、データURIスキームを使っている。その後のURLが下手に信用のおける企業のものだから、紛らわしい。データスキーム自体は、ウェブページなどによく埋め込まれているものだが、埋め込みだから、そのURIを見ることはめったにない。もしも、正常なURIだったとしたら、ブラウザのアドレスバーの先頭に、緑色の錠前マークがつくはずだ。錠前マークはSSL 接続ができていることを示している。
     (写真8)おかしなデータスキーム

 EmailのHTMLソースを確認するのも、怪しいURLを検出するのには有効だ。
 HTML上のリンクは、"HREF"フィールドの後に、実際に転送するつもりのURLが記述され、終わりに</A>タグが付く。
 「Google Login!」を誘う内容で、全くおかしなURLが記述されているとこう見える。

 <a href="http://evilsite.example.org">Google Login!</a>

 この場合、「Google Login!」クリックしたとたん「evilsite.example.org」に転送されるように、リンクが組まれている。

 リンクをクリックしたときには、緑色の錠前アイコンがあるかどうかを確かめるようにしろ。ここできちんとSSLサービスに対応しているかどうかが見分けられる。このアイコンがないのなら、「このウェブサイトの認証は正しくない」と言っているようなものだから、重要なデータを絶対に入力してはいけない。

  (写真9)緑色の錠前マーク

 フィッシング攻撃ではないか? と感じたら

 まず、最も有効な策は、怪しいと思ったメールは消してしまうことだ。
 我々が作ったセキュリティテストメールとか、本当に怪しいメールなんかは、触らない。
 次に有効なのが、GMail を使うことである。GMailには、フィッシングの疑いがあるメールを報告する機能がある。ここに入れたメールはGoogleがフィッシングとして削除してくれる。
 怪しいメールが、どうにも自分やGitLabを標的にしているような気がしたら、セキュリティチームに知らせろ。いろいろ調査しなくてはならない。
 セキュリティチームではないチームにも、Slackを使って通知することができる。フィッシングメールを張り付けるときには、セキュリティチームに許可を取ってから、添付すること。そのメールをメッセージにうめこんではいけない。

 怪しいメールを添付する時には、GMailで次の方法をとる。

  1. 返信オプションから「show original」を選択する
  2. 「download original」を選択する
  3. ダウンロードしたものを、ローカルドライブかGoogleドライブに保存する
  4. 新しいEmailを作成する時に、ドライブに保存したEmailを添付する

 「他のメールサービスでも同じようなことができるじゃないか」と思う者もいるだろうが、他のメールサービスでこの操作をしても安全かどうかの確認がとれないので、やめてもらいたい。たとえば、危険なメールとプライベートメッセージと見分けがつかなくなる可能性がある。それから、Emailのリンクは決してクリックしてはならない。

 正しいサイトへ移動するためには、予め正規のサイトにブックマークをつけて、そこから移動するか、メールのリンクをクリックするのではなく、アドレスをブラウザに手入力することで閲覧することを心がけるとよい。

 panic email アドレスを使う

 GitLabには「panic@gitlab.com」アドレスというものが存在する。チームメンバーがこのアドレスを使うのは、一刻も早くセキュリティ対策を取らなくてはならない事態になったときだ。
 これにもっともよくあてはまる事案が、チームメンバーがデバイスを紛失したときである。
 USBメモリ、Yubikey、携帯電話、タブレット、ラップトップなど、信用証明書やGitLabに関して誰かに悪用されかねないデータが入った機器を紛失したときには、すぐさま「panic@gitlab.com」にメールを送ることだ。
 このメールは productionチームと、securityチームが受け取ることになっている。このアドレスに送信があったときには、迅速に対応に当たれ。このアドレスを手がかりに、なくしたデバイスが原因で起こる損害を極力抑え込むのだ。

 パニック宣言後の対応

 開発メンバー個人がとれる、緊急事態への対策は以下の通りと想定する。
 アカウントや権限については後から復活させることができる。対策が先決だ。悪意を持った人間に不正なアクセスをされるよりは、大けがを負わずに済む。

 パニック時 対応チェックリスト(コピーして保管すること)

- [ ] パスワードにアクセスして、変更する

- [ ]1Passwordアカウントを一旦停止する(『panic@』は、1Password 『Panic@ Responders』グループメンバーと紐づけられているので、ユーザーアカウント凍結したり、解除したりする機能がある)

- [ ] 自分がアクセスできる範囲のグループや、パスワード・ヴォルトのスクリーンショットを撮影する。後から事態の収拾に役立つ。

- [ ] 重要な共有パスワードを用意するか、事態収拾までちょくちょく変更する。特に、GitLab.comのシステム管理部にアクセスするためのパスワードは、重要である。GitLabのインフラを支える要素(ssh, chef user/key, discussなど)のパスワードもこれに当てはまる。

- [ ] Google アカウントを停止する

- [ ] Slack アカウントを停止する

- [ ] [dev.GitLab.org account](https://dev.gitlab.org/admin/users)を停止する

- [ ] [gitlab-org group](https://gitlab.com/groups/gitlab-org/group_members)から、GitLab.comアカウントを削除する

- [ ] hackerone.comへのアクセスを停止する

- [ ] Tweetdeckへのアクセスを停止する

原文:https://about.gitlab.com/handbook/security/
Creative Commons License
この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス外部リンク
新着文書(Hnoss)

Signing legal documents
現在の位置: チームハンドブック 目次 >法的文書に署名する  法的文書への署名は、他社・他組織などに直接出向いてNDAsを取り扱った人物を除...
Team Handbook
現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに...
GitLab Pages documentation
  新しいドキュメント はこちらです。このドキュメントは旧式です。 GitLab Documentation > User documentation > Projects >GitLab P...
GitLab Pages
GitLab Documentation > User documentation > Projects >GitLab Pages 説明書  GitLab Pagesなら、無料でウェブサイトをホスティングできる...

新着文書

Social leader killed in Cordoba is fourth in same town in 2018
3月11日日曜日、地方評議会リーダーでアフリカ系コロンビア人の子孫であるトマス・バレトが、コルドバ県サン・ホセ・デ・ウレの自宅で殺害された。 2...

新着Wikipedia翻訳

E (programming language)
E(プログラミング言語) AmigaE や e(検証言語) 、 GNU E と混同しないこと。 E -------- パラダイム マルチパラダイム:オブジ...
Van Eck phreaking
Van Eck phreaking(ファン・エック・フリーク) Van Eck phreakingは盗聴の一形態であり、その中では特殊な装置が使用され、電子機器を探るため、隠...
Trusted Computer System Evaluation Criteria
Trusted Computer System Evaluation Criteria(信頼されたコンピュータ・システム評価基準) 【画像のキャプション】オレンジブック 信頼されたコ...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-04-03 23:23:46 Hnoss
2 2018-04-03 23:20:00 Hnoss
3 2018-04-03 23:19:23 Hnoss
4 2018-04-03 23:17:33 Hnoss
5 2018-04-03 23:11:48 Hnoss
6 2018-04-03 23:10:11 Hnoss
7 2018-04-03 23:07:48 Hnoss
8 2018-04-03 23:01:43 Hnoss
9 2018-04-03 23:01:12 Hnoss
10 2018-04-03 23:00:22 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →