2021年3月に入社した神山奎吾です。クラウドワークスではWEBエンジニアをしておりまして、Ruby（主にRails）を書いております。2021年6月現在で入社して3ヶ月になりました。
きちんとした組織で働くことが初めてで当初は不安でしたが、メンバーに恵まれたことでストレスゼロで毎日楽しく働けております。
今までの経歴が変わっているのでその視点をもとに、クラウドワークスの良いところやクラウドワークスに無いものを書いていきます。
続きを読むドメイン駆動設計 × Spring Boot（Kotlin）で新規事業クラウドリンクスを運営している話
はじめに
初めまして、クラウドワークスの新規事業エンジニアのせきと申します。2019年9月に新規事業クラウドリンクス（CrowdLinks）の開発チームにジョインし、サービスの立ち上げ段階から参画してきました。
現在クラウドリンクスは「Nuxt.js × Spring Boot（Kotlin）」という構成でサービスを運営しています。
この記事では、クラウドリンクスの技術選定の経緯と感想を紹介したいと思います。
- 新規事業の技術選定に興味がある、または今まさに技術選定をしている方
- ドメイン駆動設計などの設計思想に興味を持つ方
- 新規事業の開発に関わっている方、または関わりたいと思っている方
こんな方々のご参考になれば嬉しいです！
続きを読む週刊ポストモーテム継続への道のり
こんにちは、SREチームの @bayashi_ok です。
今回はクラウドワークスで週1回ペースで実施している「週刊ポストモーテム」の取り組みをご紹介していきます。
- ポストモーテムとは
- 週刊ポストモーテムとは
- 復刻：週刊ポストモーテム
- 障害対応した人もしくはそのチームの人が発表
- 障害がなくても開催
- ゆるく開催
- 継続して開催していくメリット
- みんなの交流の場にもなる
- 課題を見つけ、なにかをはじめるきっかけになる
- 他部門の人に知ってもらえる
- 監視ツールの使い方や見方がわかる
- 今後の課題
- 最後に
ポストモーテムとは
まずポストモーテムという単語について少し説明します。
ポストモーテムの意味は各分野でも変わっており、医学の世界では「検死」、プロジェクトマネジメントの世界では「事後検証」などの意味を指します。
SREの文脈では主に、
- 障害などが発生した際の影響
- そのとき行われたアクション
- 障害発生の根本原因
- 再発防止のためのアクション
などを記録するために書かれるもので、いわゆる「障害報告書」のようなものになります。
ただ、記録としての報告書というだけではなく、組織的な学びのために蓄積していくものだということです。
・SRE公式本（WEB無料公開版）
https://landing.google.com/sre/sre-book/chapters/postmortem-culture/
・その他参考記事
https://tech.mti.co.jp/entry/2017/11/25/000316
https://note.com/campfire_dev/n/n2a46e3832207
週刊ポストモーテムとは
週刊ポストモーテムとはこれを毎週継続的に実施して行く取り組みです。
始まりは2019年2月で、障害が発生したときに、どんな情報から・どんな判断をしているのかというのを共有する場として設けられ、実際のアラートやタイムラインの流れを見ていくなどの取り組みから始められました。
続きを読む脆弱性に対する取り組みを紹介します
始めに
皆さん、こんにちは。@shimopataです。 つい先日、ストリートファイター5のバージョンアップが行われましたね。新システムの追加で大きく戦略が変わる予感がしており、ワクワクしています。 さて、そんなスト5ですが、開発・販売元から不正アクセスによる情報漏洩があったと発表されましたね。こちらの事例はランサムウェアによる不正アクセスですが、webサービスを提供している身としては、あまり対岸の火事という気もしませんね。
私たちが運営しているクラウドワークスも、日本を超え世界中からご利用いただいております。新しいサービス・機能を提供する一方で、不正な利用を行われない様に強固なシステムを作っていく必要があります。私のチームではその様な不正利用を防ぐために、システムの脆弱性を撲滅する活動をしています。プロダクトを運営していく上での脆弱性対策に関する取り組みをトピックにした記事も少ないかと思うので、記事にさせていただきました。
取り組み全てをご紹介できるわけではありませんが、いくつかアプリケーションレイヤー層における脆弱性への取り組みをピックアップしてご紹介できたらと思います。
なぜ脆弱性に対する取り組みを行うのか
一言で表現すると「持続的なプロダクトを運営していく」ためです。 プロダクトに脆弱性があった場合、どの様なことが発生するでしょうか？ パッと思いつくだけでも
- 不正にユーザーデータが取得されてしまう。
- 不正な値を入力されることでサイトのデザインが破壊されてしまう。
- 不正にユーザーの権限昇格が行われ、本来アクセスしてはいけない管理者ページにアクセスできてしまう。
- 別のユーザーに成り代わってログインし、アカウントを乗っ取ることが出来てしまう。
など、枚挙に遑がありません。
この様な脆弱性を含んだWebサイトを頻繁に利用したいと思いませんよね？ Webサイトを提供し続けていくには、この様な脆弱性と向き合っていく必要がありますね。
脆弱性に対する具体的な取り組み
取り組みの方針は「脆弱性を検知する・減らす・増やさない」です。具体的な取り組みを次にいくつかご紹介します。
脆弱性を検知する
dependabot-alertsの活用
dependabot-alertsとは脆弱性のある依存関係を検知し、通知してくれるGithubの機能です。リポジトリのトップ画面にある、Securityタブから、Dependabot alertsを選択することで簡単に確認することが出来ます。
CrowdWorksではbundlerとyarnを使用しているため、使用しているgemやモジュールについて脆弱性が報告されると、Dependabot alertsの一覧に追加されます。
上がってきたアラートに対して、影響の調査(どの様な脆弱性なのか、自分たちのプロダクトに関係している脆弱性なのか)などを行い、対応の優先度を決めています。
しかし、公式のドキュメントにある様に、全ての脆弱性がこのアラートに上がってくる訳ではないので注意が必要です。
Note: GitHub's security features do not claim to catch all vulnerabilities. Though we are always trying to update our vulnerability database and generate alerts with our most up-to-date information, we will not be able to catch everything or tell you about known vulnerabilities within a guaranteed time frame. These features are not substitutes for human review of each dependency for potential vulnerabilities or any other issues, and we recommend consulting with a security service or conducting a thorough vulnerability review when necessary.
サイトから情報を収集する
日頃から以下で紹介するサイトをチェックすることで、いち早く新規の脆弱性報告をキャッチし、パッチを当てています。また、時間を取って過去に見つかった脆弱性に目を通し「どんな類の脆弱性が存在したか」「どのように直したのか」など多くを学ぶことができます。
Ruby on Rails: Security https://groups.google.com/g/rubyonrails-security
Ruby on Railsのセキュリティに関する報告が上がってきます。これらの更新をチームのチャンネルにPOSTしています。
GitHub Advisory Database https://github.com/advisories
パッケージ管理ツールや脆弱性の種別ごとに脆弱性レポートを参照することができます。ただし、あるリポジトリで見つかった脆弱性のすべてがここに集約されているわけではないということは覚えておかなればいけません。
HackerOne https://www.hackerone.com/
登録している企業や組織が、脆弱性を報告してくれたハッカーに報奨金を払うサービスです。 以下のアクティビティに目を通して、自社で扱っているライブラリに新たに脆弱性レポートが上がっていないかチェックします。
https://hackerone.com/hacktivity
脆弱性を減らす取り組み
brakemanの指摘を元に修正
Rubyのgemの一つにbrakemanというものがあります。このgemはRailsに対して脆弱性の観点で静的解析を行う事が出来ます。このgemを導入し、
brakeman -o output_file.html
と、実行するとコード内に存在する脆弱性が含まれる可能性のある箇所をhtmlとして一覧で出力してくれます。また、オプションによってcsv形式など、別の形式で出力可能なので、気になる方はリポジトリのreadmeをご確認ください。
この一覧を元に、一つずつ、どの様な指摘をされているのか確認し、必要があれば、脆弱性が無い形へ機能の改修、そもそも必要とされていない機能であれば、機能の削除を行いました。
正直、指摘されている個数は少なくなく、一個一個見ていくのは大変ではありましたが、指摘箇所に対して全て対応を行いました。
gem、モジュールの更新、削除
日々、ソフトウェアの脆弱性を突いた攻撃は増え続けています。当然、自分たちの書いたコードだけでなく、gemに書かれているコードもその対象です。そのため、利用しているgemやモジュールをアップデートし続けていく必要があります。全てのgemやモジュールについて、最新版がリリースされたら追従するのが望ましいですが、現実的には難しいのが実態です。
そこで、dependabot-alertsやサイトの情報などを元に対応優先度を決め、アップグレードを行っています。また、Railsなど影響範囲の大きいものに関しては、最新のセキュリティパッチがリリースされ次第すぐに対応する様にしています。
脆弱性を増やさない取り組み
PR作成時にbrakemanの実行
CrowdWorksではSiderを取り入れています。SiderではPR作成時に、様々な静的解析ツールを実行し、コードの検査を行うことが出来ます。Siderの提供している静的解析ツールの中に、brakemanがあるため、これを有効にし、脆弱性が含まれそうなコードを検知し、PRのコメントとしてエンジニアに通知をしています。
試しに脆弱性を含む可能性のあるコードを含んだPRを作成した場合、上記の画像の様にコメントしてくれます。
社内向けに勉強会の開催
機械的に脆弱性の危険性を検知し通知しようとも、通知内容がエンジニアに理解されなければ、意味はありません。そこで、brakemanの指摘を元に修正した内容を社内のエンジニア向けに勉強会を開催し、脆弱性の危険性や、どの様なコードが脆弱性となり得るのかを伝えました。
終わりに
脆弱性の対策を行うと言ってもアプリケーションの改修に限らず、検知する仕組みを作ったり、脆弱性の危険性を社内のエンジニアに伝えたり、色々行うことがあります。 利用者様に安全にクラウドワークスをご利用いただくために、日々、改善を続けていきます！！
We're hiring!
クラウドワークスでは、安心安全なシステム作りに興味のあるエンジニアを募集しています！ https://www.wantedly.com/projects/73940
