この記事は techtekt アドベントカレンダー2021 の 2日目の記事 兼 業務環境をセキュアにした話シリーズの記事です。 1日目は岡本さんの "クリスマスにまつわるTechについて徒然に書いてみる" という記事でした。 🎉🐓
こんにちは👋 テクノロジー本部 エンジニアリング統括部 サービス開発部でエンジニアをしている @_k725 です。
2020年10月頃から、サービス開発部の業務・開発環境の改善などを行ってきました。この記事を公開する時点では約1年と2ヶ月になりますね。 時の流れは速く感じます…☃🎄
これまでのおさらい兼振り返り
業務する環境をセキュアにした話 その1
コロナ渦で急遽リモートワークになり、これまで部内で利用してきたGoogle Workspaceの認証について見直していきました。
IP制限の機能を備えたアイデンティティ・プロバイダを廃止し、Google標準の認証とハードウェアセキュリティキーの導入とContext-Aware AccessとEndpoint Verificationを組み合わせ、条件に応じてアクセスの可否を決定するアプローチに切り替えました。
結果として、会社の標準であるOffice 365は利用しつつも、部内でのSaaS等の利用はGoogle WorkspaceのSAMLを基準として、Context-Aware Accessの利用による適切な制限の元、セキュアに部内でSaaSを利用出来るようになりました。
また良い副作用として、部内でSaaS等の利用を新規で始める際に、ある程度のガイドライン決めも行うことが出来ました。
業務する環境をセキュアにした話 その2
Macデバイスをそこまで必要としないが、業務上パーソルグループから標準で支給されるPCでは行えない作業などを行うメンバー向けに、コストを抑えつつ管理ポリシーが適用出来るChromebookの導入を行いました。
結果として、利用メンバーも増えつつ、オンボーディングを行うメンバー間でも知見が溜まりつつある状況で、運用のコストも減りました。
業務する環境をセキュアにした話 その3
業務で利用するパスワードや秘密鍵など、秘匿情報を安全に共有するためにパスワード管理ツールを導入した話を書きました。
自分の観測範囲では、「パスワードDMで送りますね」のようなやりとりが減っているのを見て、導入した意義を感じました。
業務する環境をセキュアにした話 番外編 〜CTF開催〜
"業務する環境" ではないですが、番外編ということで記事を執筆しました。
フロントエンドやバックエンドを開発しているエンジニアにも、セキュリティを意識して欲しい!というキッカケからCTFイベントを開催しました。
丸一日にわたり、様々な問題を解いて楽しかったとの声もあり、開催した甲斐がありました。
サービス開発時における課題
サービスの開発や公開には色々な問題が伴いますが、事業を行っていく上で特に守るべき箇所は、そのサービス自体のセキュリティや、実際に得たデータの利用についてなどです。
サービス自体のセキュリティを怠った場合、データの漏えいやサービスの改ざんによるユーザへの被害、サービス妨害による事業への影響など多岐にわたります。 また、得たデータの利用に関しても、コンプライアンスや社会通念上不適正とされた場合、会社への信頼に関わる問題なので非常に注意が必要です。
両方を意識した上、サービスの企画・開発を行っていきますが、今回はサービス開発時におけるセキュリティについて書いていこうと思います。
開発時における課題と対策
脆弱性の原因となる要因は様々ですが、書いたコードが原因で脆弱性が作り込まれてしまったり、依存しているライブラリの脆弱性により、セキュリティ上の課題が出てきてしまいます。
プルリクエスト時にレビュアーが確認することで、危険なコードを発見することも出来ますが、本来のビジネスロジックのレビューに集中が出来なかったり、レビューに割く時間を多く確保してしまうことになります。
また、パブリッククラウドを利用する上で、アプリケーションからリソースにアクセスするにあたってIAM等を利用しますが、過剰な権限を与えてしまうことで万が一の際に秘密鍵の漏えいなどが発生すると、様々なリソースにアクセスをされてしまい、情報漏えいなどが発生するリスクがあります。
ここでの課題をまとめると大体以下のようになります。
- 書いたコード起因の脆弱性検知とレビュー時のレビュアーの負担
- 依存しているライブラリの脆弱性検知
- IAMの不適切な設定
書いたコード起因の脆弱性対策
先程も書きましたが、レビュー時に全てを細かく見ることはレビュアーにとって負担になります。
コードの書き方に対する指摘はESLintなどをCIパイプラインに組み込むことで、負担をなくすことが出来ますが、セキュリティ上怪しいコードに関しては検出できません。
そこでCIパイプラインに組み込みつつ、コードの危険な部分、無駄に重複した部分や関数内の複雑度などを調査できるSonarCloudを利用してレビュアーの負担軽減に繋げつつ、セキュリティ上問題が無いかをあるチェックする体制を敷いています。
オープンソースでの利用は無料なので、著名なプロジェクトなども採用しており、プロジェクトの一覧が公開されています。
依存ライブラリの脆弱性対策
小さなライブラリから大きなライブラリまで様々な言語に便利なライブラリは存在しますが、時にはそれが原因で脆弱性の含むアプリケーションになってしまうことがあります。
JavaScript, TypeScriptのプロジェクトなどでは package.json
と package-lock.json
(npm) または yarn.lock
(Yarn) を利用してパッケージの管理を行いますが曖昧なバージョン指定だと、開発者の環境と実際にアプリケーションが動く環境で差異が出てしまったりする可能性があります。
かといって、全てを厳密なバージョン指定してしまうと、それをメンテナンスするコストが発生してしまいます。
そこで、WhiteSource Renovateを導入し、定期的なパッケージのバージョンアップを行っています。
しかし、パッケージのアップグレードによりライブラリ自体の依存関係が増え、セキュリティ上問題が発生している可能性もあります。
幸いにも同じWhiteSource社により、WhiteSource Boltという脆弱性のあるパッケージが混入した際にIssueを建ててくれるプロダクトも提供されているため、それを使用しています。
また、脆弱性が含まれるパッケージが修正・削除等されると、自動的にIssueも閉じてくれるため非常に便利です。
ただ欠点としては、依存関係の依存関係まで細かく調べてくれるお陰で、大きなフレームワークなどでプロジェクトを初期化すると、大量の脆弱性警告のIssueが建ってしまうこともあり、少し難しいところです。
また、アプリケーションを動かす上で、最近はコンテナベースで動かす機会も増えています。 当然、コンテナに採用するOSであったり、各種ランタイムに依っては脆弱性が含まれている可能性もあります。
そこで、ソースコード上依存しているライブラリだけではなく、Dockerなどのコンテナに対するスキャンも aquasecurity/trivyやGoogle Cloud PlatformのContainer scanning を利用してコンテナ自体のスキャンも行っています。
IAMの不適切な設定
Google Cloud Platformではサービスアカウントと呼ばれる、人間に紐付かないアカウントを発行することが出来、そこアカウントに対して様々な権限を付与した上で、アプリケーションの実行環境にアカウントをアタッチして権限の制御を行います。
ここで問題となるのが過剰な権限の付与で、基本は最小権限の原則に基づき権限を付与しますが、人間が管理することもあり横着して強めの権限を割り振ってしまうという可能性もあります。
そこで、定期的なプロジェクトのチェックをしつつ、権限のサジェストを行ってくれる機能を利用しつつ実際のプロジェクトで必要とされている権限などと照らし合わせて権限の管理などを行っています。
(正直、イマイチなポイントだとは思っているので今後プロセスの改善を行いたいです。)
サービス公開時における課題と対策
サービスを公開するということは基本的にインターネットにアプリケーションを露出させることが多いと思います。
公開する以上、様々なユーザがアクセスしに来て時には悪意のあるユーザが来るケースもあります。
そして、そのサービスを利用してもらう上で、しっかりとセキュリティ対策が出来ているかなどを公表・回答すべきケースもあります。
ここでの課題をまとめると大体以下のようになります。
- 悪意のあるユーザへの対策
- サービス自体のセキュリティ対策の公開
悪意のあるユーザへの対策
様々なサービスが存在するので、ここでの "悪意のあるユーザ" の定義は、サービスに負荷をかけたり攻撃を行うユーザと定義します。(SNSでは規約に違反する書き込みを行うユーザであったり、ゲームでは不正行為をするユーザなども含まれると思います。)
DDoS攻撃であったり、ネットワークに対する攻撃には、極力露出する箇所を減らした上でGoogle Cloud PlatformのCloud Armorを採用するケースが多いです。
Cloud ArmorはDDoS対策とWAF(Web Application Firewall)を備えたソリューションでCloud Load Balancingと併せて利用します。
現時点ではプレビュー版ですが、CloudFlareのUnder Attackモードに近い機能やリクエストレートでの制限を行う機能もあります。
WAFではSQLインジェクションやXSS(Cross Site Scripting)などの対策は勿論行ってくれますが、あくまで先述のコード側での脆弱性対策を基本としている状況です。
サービス自体のセキュリティ対策の公開
提供するアプリケーションの種類(主にtoB向け)によっては利用するユーザから、セキュリティチェックシートの記入依頼であったり、セキュリティ対策状況について問い合わせを受けるケースもあります。
様々なチェックシートのフォーマットであったり、質問事項の粒度がバラバラになってしまっているなどといった場合があり、問い合わせを受けたチームだけでは回答が出来ず、エンジニアに回答の依頼が来たりなどと、問い合わせから最終回答まで時間がかかってしまう状況でした。
そこで、一部のサービス(Salaries)ではセキュリティチェックシートの事前提供なども行っています。
内容としては以下の内容が含まれています。
- IPA(独立行政法人情報処理推進機構)の「安全なウェブサイトの作り方」を基準にしたチェックシート
- GoogleのVendor Security Assessment Questionnaire Frameworkを利用した回答ファイル
現状はまだ効果を計測している最中ですが、"問い合わせずとも状況が分かる" 状態を上手く作りだしていければと思います。
次回予告
次回はこれまで課題だったMacデバイスの管理について解説しようと思います。 🙋♀️
以上です。明日は前川さんによる "勘違いしていた「傾聴」の話" です。楽しみですね!
@_k725
エンジニアリング統括部 サービス開発部 第3グループ エンジニア
お寿司が好きです🍣
※2021年12月現在の情報です。