システムやWebサービスを作るとき、「セキュリティ対策が必要」と分かっていても、具体的に何を確認すればよいのか迷うことがあります。
不正ログイン、データ改ざん、情報漏えい、サービス停止、権限の不正利用など、セキュリティ上のリスクは多岐にわたります。思いついた対策だけを行っていると、重要な脅威を見落としてしまうことがあります。
そこで役立つのが、STRIDEです。
STRIDEは、セキュリティ脅威を6つの分類で整理するためのフレームワークです。初心者はまず「システムにどんな攻撃や悪用の可能性があるかを整理するチェックリスト」と理解すれば十分です。
STRIDEを使うと、システム設計や要件定義の段階で、どこに脅威があるかを考えやすくなります。セキュリティ担当者だけでなく、開発者、プロジェクトマネージャー、業務部門、DX推進担当者にも役立つ考え方です。
この記事でわかること
・STRIDEとは何か
・STRIDEは何に使うのか
・STRIDEの基本的な考え方
・STRIDEの使い方
・STRIDEの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「STRIDEはセキュリティ脅威を分類して見落としを減らすための型だ」とつかめれば十分です。
STRIDEとは？
STRIDEとは、システムに対するセキュリティ上の脅威を6つに分類して考えるフレームワークです。
STRIDEは、次の6つの英単語の頭文字を取ったものです。
・Spoofing：なりすまし
・Tampering：改ざん
・Repudiation：否認
・Information Disclosure：情報漏えい
・Denial of Service：サービス妨害
・Elevation of Privilege：権限昇格
システムのセキュリティを考えるとき、単に「不正アクセスに気をつける」だけでは不十分です。
なりすまされる可能性はないか、データを書き換えられる可能性はないか、操作ログが残らず否認される可能性はないか、機密情報が漏れる可能性はないか、サービスを止められる可能性はないか、本来持たない権限を得られる可能性はないかを整理する必要があります。
初心者向けに言い換えると、STRIDEは「攻撃者や悪用者の視点で、システムの弱点を探すための分類表」です。
一言でいうと、STRIDEはセキュリティ脅威を6種類に分けて分析するためのフレームワークです。
STRIDEは何に使うのか
STRIDEは、システムやサービスの脅威分析に使います。
主な用途は次のとおりです。
・システム設計時にセキュリティリスクを洗い出す
・Webアプリや業務システムの脅威を整理する
・認証や権限管理の弱点を確認する
・情報漏えいやデータ改ざんのリスクを考える
・要件定義でセキュリティ要件を整理する
・開発前にセキュリティ対策を検討する
・外部ベンダーにセキュリティ観点を確認する
・DevSecOpsの脅威分析に活用する
・監査やリスク評価の材料にする
・セキュリティレビューのチェックリストとして使う
STRIDEは、特に設計段階で役立ちます。
セキュリティ対策は、後から追加すると大きな手戻りになることがあります。認証、権限、ログ、暗号化、入力チェック、通信保護などは、システム設計の初期段階で考えておくべき要素です。
STRIDEを使うことで、機能要件だけでなく、セキュリティ要件も整理しやすくなります。
どんな人に向いているか
STRIDEは、次のような人に向いています。
・システム開発に関わる人
・セキュリティ設計を学びたい人
・Webアプリや業務システムを作る人
・要件定義や設計レビューを行う人
・外部ベンダーに開発を依頼する人
・情報システム部門の担当者
・DX推進でクラウドサービスを導入する人
・個人情報や機密情報を扱う部門の人
・DevOpsやDevSecOpsに関心がある人
・セキュリティリスクを整理したい管理職
STRIDEは、セキュリティ専門家だけのものではありません。
業務部門の担当者でも、基本を知っておくと役立ちます。たとえば、新しい業務システムを導入するとき、「誰がログインするのか」「誰がデータを変更できるのか」「操作履歴は残るのか」「情報漏えい時にどう検知するのか」といった確認ができるようになります。
STRIDEの基本的な考え方
STRIDEの基本は、脅威を6つに分けて考えることです。
Spoofing なりすまし
Spoofingは、本人ではない人が本人のふりをする脅威です。
たとえば、次のような例があります。
・他人のIDとパスワードでログインする
・管理者になりすまして操作する
・偽のWebサイトで利用者をだます
・APIの呼び出し元を偽装する
・メール送信者を偽装する
なりすまし対策としては、多要素認証、強固な認証、証明書、アクセス制御、ログ監視などが考えられます。
Tampering 改ざん
Tamperingは、データや処理内容が不正に書き換えられる脅威です。
たとえば、次のような例があります。
・注文金額を書き換える
・承認ステータスを不正に変更する
・ログを削除または改ざんする
・通信中のデータを書き換える
・設定ファイルを書き換える
改ざん対策としては、入力チェック、権限管理、改ざん検知、署名、暗号化、操作ログ、変更管理などが考えられます。
Repudiation 否認
Repudiationは、後から「自分はその操作をしていない」と否定できてしまう脅威です。
たとえば、次のような例があります。
・誰が承認したのか記録がない
・誰がデータを削除したのか分からない
・操作ログが残っていない
・ログが改ざん可能になっている
・重要操作に本人確認がない
否認対策としては、操作ログ、監査ログ、電子署名、タイムスタンプ、承認履歴、ログの改ざん防止などが考えられます。
業務システムでは、承認、削除、権限変更、請求処理などで特に重要です。
Information Disclosure 情報漏えい
Information Disclosureは、本来見せてはいけない情報が漏れてしまう脅威です。
たとえば、次のような例があります。
・個人情報を権限のない人が閲覧する
・URLを知っていれば資料が見られる
・通信が暗号化されていない
・ログにパスワードが出力される
・クラウド共有設定が公開になっている
・エラーメッセージに内部情報が出る
情報漏えい対策としては、アクセス制御、暗号化、データ分類、マスキング、ログ管理、共有設定管理、最小権限などが考えられます。
Denial of Service サービス妨害
Denial of Serviceは、システムやサービスを使えない状態にする脅威です。
たとえば、次のような例があります。
・大量アクセスでサービスを停止させる
・サーバー資源を使い切らせる
・データベースに高負荷をかける
・重要ファイルを削除して業務を止める
・アカウントロックを大量発生させる
サービス妨害対策としては、負荷対策、レート制限、監視、冗長化、バックアップ、障害対応計画、WAFなどが考えられます。
Elevation of Privilege 権限昇格
Elevation of Privilegeは、本来持っていない高い権限を得てしまう脅威です。
たとえば、次のような例があります。
・一般ユーザーが管理者機能を使う
・URLを直接入力して権限外画面にアクセスする
・権限チェックの不備を突く
・脆弱性を使って管理者権限を得る
・設定ミスにより不要な権限を持つ
権限昇格対策としては、アクセス制御、権限チェック、最小権限、脆弱性対策、管理者権限の制限、定期的な権限棚卸しなどが考えられます。
STRIDEの使い方
手順1 分析対象を決める
まず、STRIDEで分析する対象を決めます。
対象が広すぎると分析がぼやけるため、最初は特定のシステム、機能、画面、業務プロセスに絞るとよいでしょう。
たとえば、次のような対象です。
・ログイン機能
・顧客情報管理機能
・申請承認機能
・ファイル共有機能
・API連携
・決済処理
・管理者画面
・外部委託先向けポータル
対象を決めることで、具体的な脅威を考えやすくなります。
手順2 データと利用者を整理する
次に、対象機能で扱うデータと利用者を整理します。
確認する観点は次のとおりです。
・誰が使う機能か
・どのデータを扱うか
・機密性の高い情報はあるか
・どのシステムと連携するか
・外部からアクセスされるか
・管理者機能はあるか
・ログや履歴は残るか
STRIDEでは、守るべき対象を把握することが重要です。
手順3 6つの脅威で問いかける
次に、STRIDEの6分類を使って問いかけます。
たとえば、ログイン機能なら次のように考えます。
・なりすましされる可能性はないか
・認証情報が改ざんされる可能性はないか
・ログイン操作を否認される可能性はないか
・パスワードや個人情報が漏れる可能性はないか
・大量ログイン試行でサービス妨害されないか
・一般ユーザーが管理者権限を得る可能性はないか
このように6つの視点で確認すると、見落としが減ります。
手順4 リスクの大きさを考える
洗い出した脅威について、リスクの大きさを考えます。
すべての脅威に同じ強さで対策することは現実的ではありません。
確認する観点は次のとおりです。
・発生した場合の影響は大きいか
・発生する可能性は高いか
・個人情報や機密情報に関わるか
・業務停止につながるか
・法令違反や信用低下につながるか
・外部から攻撃されやすいか
・既存対策はあるか
影響が大きく、発生可能性も高い脅威から優先的に対策します。
手順5 対策を検討する
次に、脅威に対する対策を検討します。
たとえば、次のような対策です。
・多要素認証を導入する
・入力値チェックを行う
・通信を暗号化する
・操作ログを残す
・権限チェックを強化する
・重要操作に承認を入れる
・バックアップを取得する
・アクセス制限を設ける
・監視アラートを設定する
・脆弱性診断を行う
対策は、技術だけでなく運用ルールも含めて考えます。
手順6 要件や設計に反映する
最後に、洗い出した脅威と対策を、要件定義や設計に反映します。
たとえば、次のように落とし込みます。
・ログインには多要素認証を必須にする
・管理者操作は監査ログを残す
・個人情報は権限を持つ人だけ閲覧できる
・重要データの削除には承認を必要とする
・ファイル共有には期限と権限制限を設定する
・異常アクセスは管理者に通知する
STRIDEは、分析して終わりではなく、実際の要件や設計に反映して初めて意味があります。
STRIDEの具体例
例 社内申請システムを分析する場合
社内申請システムを例に考えます。
このシステムでは、社員が申請を作成し、上司が承認し、経理や総務が処理します。申請には、金額、理由、添付ファイル、承認履歴などが含まれます。
STRIDEで分析すると、次のような脅威が考えられます。
Spoofingでは、他人のアカウントでログインし、申請や承認を行うリスクがあります。
Tamperingでは、申請金額や承認ステータスが不正に書き換えられるリスクがあります。
Repudiationでは、誰が承認したのか記録が残らず、後から否認されるリスクがあります。
Information Disclosureでは、申請内容や添付ファイルを権限のない人が閲覧するリスクがあります。
Denial of Serviceでは、申請締切日にアクセス集中でシステムが使えなくなるリスクがあります。
Elevation of Privilegeでは、一般社員が管理者画面にアクセスし、承認ルートを変更するリスクがあります。
対策としては、多要素認証、権限管理、承認ログ、アクセス制限、バックアップ、監視、管理者機能の制限などが考えられます。
別の例 顧客情報管理システムを分析する場合
顧客情報管理システムでは、顧客名、連絡先、商談履歴、契約情報、問い合わせ履歴などを扱います。
STRIDEで分析すると、次のようになります。
Spoofingでは、営業担当者になりすまして顧客情報にアクセスするリスクがあります。
Tamperingでは、顧客の連絡先や契約条件を不正に変更するリスクがあります。
Repudiationでは、誰が顧客情報を変更したのか分からないリスクがあります。
Information Disclosureでは、担当外の顧客情報や機密契約情報が漏れるリスクがあります。
Denial of Serviceでは、営業活動中にシステムが停止し、顧客対応ができなくなるリスクがあります。
Elevation of Privilegeでは、一般ユーザーが全顧客データをエクスポートできるようになるリスクがあります。
対策としては、担当者別のアクセス制限、操作ログ、データエクスポート制限、通信暗号化、監視、バックアップ、管理者権限の制限などが考えられます。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・STRIDEは脅威を分類して考えるために使える
・認証、権限、ログ、情報漏えい、可用性を幅広く確認できる
・業務システムでもセキュリティ脅威は多い
・重要操作にはログや承認が必要になる
・機密情報はアクセス制御が重要である
・サービス停止もセキュリティ上の脅威である
・分析結果は要件や設計に反映する必要がある
STRIDEは、システムの弱点を発見するための実務的なチェックフレームです。
STRIDEを使うメリット
STRIDEを使うメリットは、セキュリティ脅威を体系的に洗い出せることです。
主なメリットは次のとおりです。
・セキュリティリスクの見落としを減らせる
・設計段階で脅威を考えられる
・認証や権限管理の不備に気づきやすい
・情報漏えいや改ざんのリスクを整理できる
・ログや監査証跡の必要性を確認できる
・サービス停止リスクも考えられる
・外部ベンダーへの確認観点になる
・セキュリティ要件を作りやすくなる
・DevSecOpsに取り入れやすい
・業務部門ともリスクを共有しやすい
特に大きなメリットは、セキュリティを後回しにしにくくなることです。
設計段階でSTRIDEを使えば、後から大きな手戻りになる前に、必要な対策を検討できます。
STRIDEを使うときの注意点
STRIDEは便利ですが、使い方を間違えると、単なるチェック作業になってしまいます。
よくある失敗例は次のとおりです。
・形式的に6分類を埋めるだけになる
・業務上重要なデータを把握していない
・攻撃者の視点で考えられていない
・リスクの優先順位をつけない
・対策を要件や設計に反映しない
・ログや運用対応を見落とす
・外部連携やAPIを分析対象から外す
・管理者機能のリスクを軽視する
・セキュリティ担当者だけで分析する
・分析結果を更新しない
特に注意したいのは、STRIDEは脅威を洗い出す道具であり、対策そのものではないという点です。
脅威を見つけたら、実際の設計、権限、ログ、監視、運用ルールに反映する必要があります。
また、システムが変われば脅威も変わります。新機能追加、外部連携追加、クラウド移行などのタイミングで、再度見直すことが重要です。
関連フレームワークとの違い
STRIDEと関連するフレームワークには、Zero Trust、COBIT、ITIL、DevOps、要件定義フレームなどがあります。それぞれ目的が異なります。
Zero Trustとの違い
Zero Trustは、すべてのアクセスを検証するセキュリティアーキテクチャの考え方です。
STRIDEは、システムにどのような脅威があるかを分類して分析するフレームワークです。
STRIDEで脅威を洗い出し、その対策としてZero Trustの考え方を取り入れる、という使い方ができます。
COBITとの違い
COBITは、ITガバナンスとITマネジメントのためのフレームワークです。
STRIDEは、より具体的なシステムや機能の脅威分析に使います。
COBITが経営視点でITリスクを管理するための枠組みだとすれば、STRIDEは個別システムのセキュリティリスクを洗い出す道具です。
ITILとの違い
ITILは、ITサービス管理のフレームワークです。
インシデント管理、問題管理、変更管理などを扱います。
STRIDEは、脅威を事前に分析するために使います。ITILは、運用中に発生したインシデントへの対応や改善に役立ちます。
DevOpsとの違い
DevOpsは、開発と運用が連携して継続的に価値を届ける考え方です。
STRIDEは、開発や設計の中でセキュリティ脅威を洗い出すために使えます。
DevOpsにセキュリティを組み込むDevSecOpsでは、STRIDEのような脅威分析が役立ちます。
要件定義フレームとの違い
要件定義フレームは、業務要件、機能要件、非機能要件を整理するための考え方です。
STRIDEは、特に非機能要件の中でもセキュリティ要件を整理する場面で役立ちます。
たとえば、顧客情報管理システムの要件定義で、STRIDEを使って情報漏えい、なりすまし、権限昇格のリスクを確認できます。
STRIDEはどんな場面で使うと効果的か
STRIDEは、次のような場面で使うと効果的です。
・新しいシステムを設計するとき
・セキュリティ要件を整理するとき
・WebアプリやAPIを開発するとき
・個人情報や機密情報を扱うシステムを作るとき
・外部連携を追加するとき
・管理者機能を設計するとき
・クラウドサービス導入前にリスクを整理するとき
・外部ベンダーの設計レビューを行うとき
・DevSecOpsを取り入れたいとき
・システム改修時にセキュリティ影響を確認するとき
特に、設計段階で使うと効果的です。
後からセキュリティ対策を追加するより、最初から脅威を考えて設計したほうが、手戻りを減らせます。
まとめ
STRIDEとは、セキュリティ脅威を6つに分類して分析するためのフレームワークです。
Spoofingはなりすまし、Tamperingは改ざん、Repudiationは否認、Information Disclosureは情報漏えい、Denial of Serviceはサービス妨害、Elevation of Privilegeは権限昇格を意味します。
STRIDEを使うと、システムやサービスにどのような脅威があるかを体系的に洗い出せます。認証、権限、ログ、情報保護、可用性、管理者機能などを幅広く確認できます。
大切なのは、脅威を洗い出して終わりにしないことです。分析結果を、要件定義、設計、開発、テスト、運用に反映する必要があります。
まずは、自社や自部門で使っている重要なシステムを1つ選び、STRIDEの6分類に沿って「どんな悪用や攻撃があり得るか」を書き出すところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
Zero Trustとは？初心者向けに意味・使い方・具体例をやさしく解説
COBITとは？初心者向けに意味・使い方・具体例をやさしく解説
要件定義フレームとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
