快適なリモートワークを実現するために〜RailsでSSOを実現する3パターン
下重 博資
GMOペパボ株式会社
shimoju.icon
下重 博資（しもじゅう ひろし）
最近は冷凍弁当宅配サービスのnoshをひたすら食べる生活をしています 発表資料
SUZURIではScrapboxを活用しており、雰囲気が感じられるようにしてみました
宣伝
SUZURIにてKaigi on Rails公式グッズ販売中です！！！！！
https://gyazo.com/aa7a9ccb047af16a97ca411c3a50f779
ちょうど寒くなってきたのでパーカーとかいいですね
1月27日、突然の在宅勤務
年1回の在宅勤務訓練や、台風や猛暑時の臨時在宅勤務はあった
全面的かつ長期間の在宅勤務は初めて
VPNの速度低下
オフィスのIPアドレスで制限している社内ツールや管理画面の存在
なぜIPアドレス制限？
「アクセスしようとしている人がオフィス内にいること」が検証できる
IPアドレスの偽装は困難という前提であれば
パスワードが漏洩してもオフィス内にいなければアクセスできない
オフィスへの入退室はIDカードや警備員によって管理されている
出社勤務であれば手軽な不正アクセス軽減手段であった
二要素認証ではどうか？
SUZURI事業部ではいくつかのサービスを管轄している
このうちSUZURIでは今年から二要素認証(TOTP)を提供開始 SUZURIではこれを流用して管理画面へのアクセス制限として使えないか？と考えた
セキュリティ・内部統制上の要件
セキュリティ対策部署で聞いたところ、以下が必要との回答
アカウント管理の即時性の担保
閲覧・操作ログの整備
管理者アカウントの作成時に情報セキュリティ管理者による承認を経ているか証跡を残す
アカウント管理の即時性
端末紛失時や退職時に速やかに権限を無効にできる体制が整っているか
コーポレートエンジニアリンググループが管理しているツールであればフローがある
部署内の退職フローはあるが、速やかかと言われるとそうではない
つまり、単なる二要素認証だけでは要件として不足している
部署ごとに整備をするのはコストがかかるため、上の仕組みに乗るのがベスト
ペパボの認証基盤
各サービスとはSAMLで連携し、アプリごとにアクセスできるロールを管理
SUZURI事業部のツールや管理画面についても、SAMLを用いて認証を行うことにした
Security Assertion Markup Languageの略
シングルサインオン、シングルログアウトといったID連携を実現する仕様のひとつ
SP-initiated flow
サービスプロバイダ(連携する側)を起点とするフロー
IdP-initiated flow
アイデンティティプロバイダ(連携される側)を起点とするフロー
実装パターン
パターンA
管理者アカウントが通常アカウントと独立している
ユーザーが社内のみであるツール、管理用アプリが独立している
同一アプリ内にあってもUserモデルとAdminモデルと分かれている場合
この場合は一番簡単で、管理者アカウントのパスワード認証をやめてSAML認証に移行すればOK
どう？
READMEの通りに実装するだけでSAML認証ができる
ただし細かいカスタマイズは難しい
シングルログアウトの挙動にやや難があり、ログアウトリクエスト中にcurrent_*を参照するとOneLogin::RubySaml::ValidationErrorが発生してしまった
ログにログイン中のユーザーIDを書き出していたところがエラー
採用中止も検討したが、実装の省力化のメリットの方が大きいと判断
saml_session_index_key
READMEの記述がわかりにくいが、IdP-initiated SLOに対応するためには Deviseモデルにstringなカラムを作成
そのカラム名をconfig.saml_session_index_keyに指定
が必要となる
パターンB
管理者アカウントが通常アカウントと同一で、権限設定により管理画面へのアクセスが可能となる
Userモデル内にrole: :adminみたいなカラムがある場合
管理者アカウントに限ってログイン方法を変えたりパスワードログインを無効化したりするのは煩雑そう
通常のサービスログインはパスワード認証のまま、管理画面へのアクセスの際にSAML認証を要求するようにした
OneLoginが開発しており、devise_saml_authenticatableも内部ではこれを使っている
ラッパークラスを作ると見通しがよくなると思う
コードの文脈結構わかりにくいと思うので何かあればAfter Partyで聞いてください
パターンC
アプリに認証機能がない・コードの改変が難しい
レガシーアプリで内部実装に手がつけられない場合や、非OSSでコードの改変が難しい場合
アプリの外からアクセス制御できるoauth2-proxyを採用
その名の通りリバースプロキシのように動作し、アプリの前段でリクエストを受け付ける
設定したProviderの認証が通ればプロキシする
https://cloud.githubusercontent.com/assets/45028/8027702/bd040b7a-0d6a-11e5-85b9-f8d953d04f39.png
Providerをどうするか
oauth2-proxyはSAMLには対応していない
これをProviderとして使うことで、SAMLと同様にOneLogin側の権限管理を使ってバックエンドへのアクセスを制御できるようになる
閲覧・操作ログの整備
リスク統制の基本的な観点
予防的統制
誤りや不正が発生しないように設計する
事前予防。例：バリデーションで壊れたデータの投入自体を防止する
発見的統制
誤りや不正を検知し、影響範囲の特定や是正ができるようにする
事後発見。例：侵入検知システム、アクセスログの取得
予防的統制
ログインの試行回数制限(Rate Limit)を実装
社員であっても必要な人以外はアクセスできない
OneLoginでロール管理をしている
権限を最小化する
権限を細かく分けて必要な分だけ設定するなど
これは今のところできていない
発見的統制
アクセスログにログイン中のユーザーIDを書き出すようにし、いつ誰が何の操作をしたかがわかる
すべてのSQLクエリログを取得しており、具体的に実行されたSQLを特定可能
管理画面で重要な操作をしたときにSlack通知する
管理者アカウントの作成時に情報セキュリティ管理者による承認を経ているか証跡を残す
長い
情報セキュリティ管理者
サービスごとに定めており、基本的にはそれを管轄する部署の(エンジニアリング)マネージャー
OneLoginの権限変更はWeb画面から行えるが、承認管理のような高度な機能はない
今までは口頭ベースだったが、今後は管理者アカウントの作成について稟議の提出が必要となる可能性
エンジニアリングの手法で証跡管理したい
我々にはGitHubがある
Pull Requestを提出し、情報セキュリティ管理者がレビューする運用にすれば統制できる
既にSlackのユーザーグループをYAMLで管理していたのでアイデアはあった
神が現れた
このYAMLを管理するGitHubリポジトリを作り、マージするとCIでAPIを通して変更を適用する
これでPull Requestを通して証跡を残すことができるようになった！
まとめ
在宅勤務で障壁となるIPアドレス制限の排除に取り組んだ
SSOの実装パターンを3種類紹介した
予防的統制と発見的統制の両面から対策を行う
権限はテキストで管理し、Pull Requestを通して承認する
快適なリモートワークライフを！