この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
最初に
2023年4月21日(金) 幕張メッセで開催された AWS Summit Tokyo 2023 に参加しました！視聴させていただいたセッションは下記です。
Gunosy（グノシー）が選んだ開発者に負担をかけないスマートなセキュリティ対策
本レポート記事の投稿につきまして
本記事を投稿させていただくにあたり、Snyk 様、Gunosy 様 にご承諾いただけましたので、公開させていただいております。 また、Gunosy ご登壇者様には内容の訂正についてご指摘もいただき、修正して公開させていただきました。大変失礼いたしました。修正点につきまして、ご教授いただき誠にありがとうございます！
登壇者です
レポートありがとうございます
いくつか訂正を
Inspector → Snyk への変更はECRリポジトリのScanです。EC2のScanはInspectorの使用を継続しています。
「ルールや無視したい項目を一括に設定もできた」はIa C Scanの項目での発言でした。https://t.co/TfHuZw0zJv— YAMAGUCHI Takashi (@yamaguchi_tk) April 24, 2023
また、Gunosy 様で AWS Summit Tokyo 2023 にご参加された様子を記事化されておりますので、下記をご確認ください。
AWS Summit Tokyo 2023 に参加してきました | Gunosy Tech Blog
セッション概要
Log4Shell 事件をきっかけに、網羅的なセキュリティ対策を検討し始めた Gunosy （グノシー）は、人海戦術ではなくスマートなセキュリティ対策として開発者に負担をかけない Snyk（スニーク）を導入されました。本セッションでは、なぜ Gunosy が開発者セキュリティの Snyk を選んだのかについて実際に担当者様にお聞きします。具体的には、導入前の課題や検討のプロセスなどリアルなお声をざっくばらんにお話しいただきます。また、Snyk の導入効果についてもご紹介します。
スピーカー
- Snyk株式会社 シニアソリューションエンジニア 相澤 俊幸 氏
- 株式会社Gunosy 技術戦略室 SREチーム マネージャー 山口 隆史 氏
レポート
Shift Left を目指す
安全な開発を迅速に行えるようにしたい。
- これまでのセキュリティの修正プロセス
１つずつ問題を解消していた。これだと、後々大変なので、上流から対応したい。創業者のガイ・ポジャーニー氏も、当時のツールでは、想定以上の時間を有し、不要な検知情報が散見されたことで、精度に疑問を抱き、もっと開発者に負担をかけないスマートなソリューションが必要と考え、Snyk を創業。
新たなセキュリティ対策モデル DevSecOps
開発はウォーターフォールが主流の時代。１つ１つの課題をクリアしていたが、現在では、継続的な DevOps のようなアプローチが必要だと考えた。
- 継続的プロセス
- 開発をスピーディに
- 自律的チーム
- 開発者が自律的に動ける
- 作業の自動化
- 自動化にツールを利用する
Snyk が支える開発者セキュリティ
Snyk は、１つのプラットフォームで、下記のすべてを行える。
- Developer Security プラットフォーム
- Snyk Code
- Snyk Open Source
- Snyk Container
- Snyk IaC
- Snyk Cloud
IDE のインラインを自動スキャン → コードの脆弱性を検出 → 修正支援
PR スキャン、CI/CD、テストなどでオープンソースの脆弱性を検出 → 修正支援
コンテナイメージ、k8s アプリケーションなどの脆弱性を検出 → 修正
Terraform、CloudFormation、k8s、ARM テンプレートの設定を検出 → 修正
Snyk IaC と連携して、クラウドインフラの構造をスキャン → 事前定義したセキュリティルールと比較 → 修正
- 実行例
- Code（Test、Fix）
- Git repository（Test、Fix、Monitor）
- CI/CD（Test、Fix、Monitor）
検知 > 修正 > 予防 > 監視 > 管理 をループしてサイクルを回せる。
コードの脆弱性や、ライセンスポリシー違反の発見。ポリシーに基づき、PR をブロックする。新たな脆弱性を検知したら、JIRA Issue の自動生成
Fix PR により修正、パッチ適用、アップグレードされ、マージ
CI に組み込まれた脆弱性とライセンス違反の自動テスト。失敗 → ポリシーに従い、ビルドブロック
その他、新たな脆弱性を検出したら、アラート発報（Slack）、JIRA の Issue 生成
Gunosy が Snyk を選んだ理由
- セキュリティ対応開始の背景
- Log4j の脆弱性問題
- 調査が人力総力戦で、非常に疲弊したため、二度と繰り返したくなかった。
- 定期的なスキャンを自動的に継続するサイクルを回して、問題をつぶしたい。
個人が SNS などで最新の脆弱性情報を収集していた。
Securityの設計はベストプラクティスに沿っていたが、実装者のスキル任せになっていた。
- Gunosy 開発チーム体制
- 開発チーム
- 開発チームと SRE との責任分担
Gunosy、ニュースパス、au サービス Today、広告配信などに機械学習チーム、SRE チームが横断的に対応
開発チーム：CI/CD、監視、EKS/ECS 等インフラの民主化が出来ている。
（アプリ開発/運用、モニタリング設定、セキュリティ/脆弱性対応、EKS/ECS 運用、EKS VersionUP、コスト管理、CI/CD 運用、インフラ運用管理、AWS 環境設定、オンコール対応、障害対応）
SRE：開発チームが新たなプロダクト価値の創造に集中できる状態を作るのがミッション
ふりかえりの実施、SLI/SLO 管理運用、全体的なガードレール運用、アクセス権限管理、自動化/標準化、障害対応（ポストモーテム）
- デプロイパイプラインの特徴
- PR マージでオーケストレータへのコンテナ配置まで自動化する CI/CD を構築（一部リポジトリを除く）
- 自動テストが遅い場合は、Argo CD を使って、CI と CD を分割している
CI/CD で脆弱性チェック → 開発に集中できるので、対応が早く負担が少ない
- IaC スキャンを Snyk に任せられた
- 無視したいルール / したくないルールを一括に設定できた
- 検知した設定ミスの修正について、詳細な修正情報も得られた
- ECR リポジトリのスキャンを Inspector → Snyk へ移行
- Inspector では、オーケストレーターのどの項目など、単体とか選べなかった。今使ってるイメージだけをスキャンしたかったので、Snyk のタグ機能を使用して、必要なスキャンだけに絞れた。
- 脆弱性に対して、どのイメージ使えばどのぐらい減るかをマイナーアップデートする前に教えてくれる。メジャーにアップデートする前に決められる。あげても直らない場合は「依存ライブラリを違うものに変更すると良い」なども教えてくれる。
- どう書けば、コード的に正しいのか？ベストプラクティスも教えてくれる。どこまで直せば良いのか？も教えてくれる。
- EC2 の Scan は、継続して Inspector を使っている
- Security Hub → Security Lake への移行理由
- マルチアカウントに向いてなかった
- ダッシュボードが見やすくなった
アカウント別に情報を絞るのに苦労するため、トリアージに時間がかかった。検索条件も保存できなかった。
まとめ
コードをどこまで直したらいいのか詳細に知れて、さらにその時のベストな書き方もサポートしてくれるということで、セキュリティチームではなく開発者サイドでリアルタイムに対応が出来るようになったとのことで、非常に効率化が図れたとのことでした。さらにこうしたソリューションの導入コストはあっても、結局のところ人的リソースや、工数の削減につながり、ストレスフリーな開発をスムーズに行えるようにある程度地盤が整っているのが SaaS 製品の強みであり、開発者ライクな部分は Snyk の特徴的な部分だと感じました。本セッションでは、実際の課題やどのようなプロセスを経て活用に至ったのかを具体的にご説明いただき、非常にわかりやすく、学びがありました。同じようにコードや IaC などの脆弱性を継続的にスキャンしていくことが、セキュリティインシデントを防ぐために必要な時代になっていると思いますので、もし読んでいただいた方の中で Snyk で解決出来そうな課題をお持ちであればご検討してみてはいかがでしょうか。
0
