APIとは何か(3)
~APIセキュリティのベストプラクティス~

Share

APIセキュリティは、適切な認証と認可が鍵です。本記事では、APIのセキュリティを強化するための基本的な対策からベストプラクティスまで解説します。脅威に対抗するための対策案を紹介し、セキュアなAPI運用のポイントを提供します。

前回記事はこちら。
シリーズ第1回目「APIとは何か(1)~基本概念とセキュリティの重要性~
シリーズ第2回目「APIとは何か(2)~APIの脅威とリスク~

認証と認可の重要性

ソフトウェアセキュリティにおける問題の多くは、信頼境界をまたぐデータ(プログラム内の入出力)やモノ(フレームワーク)に起因しています。様々な場所から様々なデバイスによりアクセスされる昨今の環境下では、既存の認証を信用せず、あらゆるアクセスを信用しないという前提に立った上で動的なアクセスコントロールによって認可する「ゼロトラスト」の考え方が必要です。ポイントは、「認証」と「認可」の違いを的確に理解することです。「認証」と「認可」が適切に区別されていないシステムの場合、本人確認を行うユーザ認証さえ突破してしまえば、システムのどこにでも自由にアクセス可能となってしまい、非常に危険です。

「認証」と「認可」を明確に区別して信頼境界の安全を保つことが重要であり、その実現にあたっては、厳格なセッション管理が鍵となります。代表例として、ソフトウェアにおけるアクセス認可において、アクセストークンによる堅牢な制御の上で、信頼境界ごとのリソースに認可プロセスを設定するといった方法が挙げられます。

基本的なセキュリティ対策

セキュリティ対策の取り組みには、基本的なセキュリティ対策こそが効果的であるという前提に立って、今一度自組織のセキュリティを見直すことが重要です。

セキュリティ基本10項目

標的型攻撃メール訓練の実施

標的型攻撃メール訓練は、従業員のセキュリティ意識向上と実践的なスキル習得に効果的です。訓練では、攻撃メールを模倣したシナリオを用いて、従業員が疑わしいメールを識別し、適切に対応するスキルを養います。定期的な訓練実施により、従業員のセキュリティ意識が継続的に高まり、実際の攻撃に対する組織の耐性が強化されます。また、訓練後のフィードバックやセキュリティ教育との組み合わせにより、より効果的な対策が可能になります。

定期的なバックアップの実施と安全な保管(別場所での保管推奨)

ランサムウェアによる被害からデータを保護するために、サーバに対してオフラインバックアップ(データだけを独立して磁気テープ・ストレートなどで物理的に隔離しておくこと)を行うことがおすすめです。バックアップの頻度や保管場所を見直し、最新の情報が常に保存されるようにすることが重要です。

バックアップ等から復旧可能であることの定期的な確認

バックアップが確実に復旧可能であることを確認するため、定期的にリカバリーテストを実施します。これにより、実際の復旧作業時に問題が発生しないことを保証し、緊急時に迅速かつ確実なデータ復旧が可能となります。また、テスト結果を文書化し、必要に応じて復旧手順の改善を図ります。このような確認作業を怠ると、いざという時にデータ復旧が困難になるリスクが高まります。

OS、各種コンポーネントのバージョン管理、パッチ適用

システムの脆弱性を悪用する攻撃を防ぐためには、OSやソフトウェアコンポーネントの最新バージョンへの更新・パッチ適用の実施をすることが必要不可欠です。定期的なパッチ適用とバージョン管理により、サイバー攻撃のリスクを大幅に軽減できます。特にゼロデイ攻撃のリスクを軽減するためには、普段から脆弱性関連の情報収集やバージョン更新が求められます。

認証機構の強化(14文字以上といった長いパスフレーズの強制や、適切な多要素認証の導入など)

認証の強化は、サイバー攻撃から組織を守るための基本的な対策です。単純なパスワードではなく、長く複雑なパスワードにし、さらに多要素認証(MFA)を導入することを推奨します。多要素認証はパスワードに加え、物理トークンや生体認証などの認証要素を用いることで、不正アクセスされるリスクを低減します。これにより、アカウントのセキュリティが飛躍的に向上します。

適切なアクセス制御および監視、ログの取得・分析

システム内の情報やリソースへのアクセスを厳格に管理し、適切なアクセス制御を行うことは、内部からの不正行為を防ぐために重要です。また、システムの稼働状況やアクセスログを定期的に取得し分析することで、異常な挙動を早期に検知できます。

シャドーIT(管理者が許可しない端末やソフトウェア)の有無の確認

シャドーITは、組織のセキュリティポリシーに反する可能性があり、脆弱性やデータ漏洩の原因となることがあります。定期的な監査や従業員への教育を通じて、シャドーITの存在を確認し、適切な対策を講じることが重要です。

攻撃を受けた場合に想定される影響範囲の把握

サイバー攻撃を受けた際に、どのような影響が組織に及ぶかを事前に把握しておくことは重要です。影響範囲を明確にすることで、インシデント発生時の対応計画を具体化し、迅速な対策を講じることが可能になります。システム全体の依存関係や業務の優先度を考慮し、被害を最小限に抑えましょう。

システムのセキュリティ状態、および実装済みセキュリティ対策の有効性の確認

定期的にシステムのセキュリティ状態を確認し、現在のセキュリティ対策が有効に機能しているかを確認することが効果的です。脆弱性診断やペネトレーションテストを実施することで、システムの弱点を特定し、自組織の状況に適した対応の実施が可能になります。

CSIRTの整備(全社的なインシデントレスポンス体制の構築と維持)

CSIRT(Computer Security Incident Response Team)は、サイバー攻撃やインシデント発生時に迅速かつ適切な対応を行うための専門チームです。CSIRTの整備は、全社的なセキュリティ体制を強化し、インシデント発生時の被害を最小限に抑えるために不可欠です。定期的な訓練とシミュレーションを通じて、CSIRTの対応力を維持し、常に最新の脅威に対応できる体制を整えます。

APIセキュリティのベストプラクティス

OAuthトークン

OAuthトークンは、APIへのアクセスを安全に制御するための認可手段です。ユーザのパスワードを直接共有せず、一時的なトークンでアクセスを許可する仕組みにより、不正アクセスのリスクを軽減します。

暗号化と署名

API通信では、暗号化が重要です。また、署名による送信者の認証をすることも重要です。SSL/TLS(TLS 1.3推奨)での暗号化により、データが送受信される途中で盗聴されないようにします。署名には一般的にRSA暗号やECDSAなどのアルゴリズムが使用され、SHA-256などのハッシュ関数と組み合わせてデータの完全性を保証します。デジタル証明書を使用することで、通信相手の身元確認も可能になり、より強固なセキュリティを実現できます。

レート制限とスロットリング

レート制限とスロットリングは、APIへのリクエスト数を一定範囲に抑え、サーバへの負荷を管理するための手法です。過剰なリクエストをブロックし、DDoS攻撃などのリスクを軽減します。また、正規ユーザの快適な利用を維持し、サービスの安定稼働を支えます。

APIゲートウェイの使用

APIゲートウェイは、API管理を一元化するためのツールです。認証、認可、レート制限、監視など、APIに関連するセキュリティ機能を提供します。これにより、システム全体のAPI運用を最適化します。APIの脆弱性を効果的に軽減することができます。また、監視とログ収集を行うことで、問題発生時の迅速な対応が可能になります。

APIのセキュリティ対策

ここまで見てきたAPIセキュリティ脅威を踏まえると、以下のようなポイントにおいて脆弱でないことが重要と考えられます。

APIのセキュリティ対策のポイント図

開発中、リリース後、更新時といった、いかなる状況においても、適切な脆弱性管理・対応ができているかどうかが、鍵となります。

APIのセキュリティ対策の概要図

APIの開発にあたっては、DevSecOpsを適用して脆弱性を作り込まないようにすること、APIリリース後も、新たな脆弱性が生まれていないか、APIセキュリティ診断などを通じて確認を継続することが重要です。

APIはスマホアプリでも多く活用されています。誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。スマホアプリのセキュリティ対策の一つとしては、信頼できる第三者機関による脆弱性診断の実施があげられます。第三者の専門家からの診断を受けることで、網羅的な確認ができるため、早急に効率よく対策を実施するのに役立つでしょう。

関連記事:

  • 攻撃者が狙う重要情報の宝庫!―スマホアプリのセキュリティ―
  • まとめ

    APIのセキュリティについて、認証と認可は基本となる重要な要素です。現代では従来の境界型セキュリティでは不十分となり、あらゆるアクセスを疑う「ゼロトラスト」モデルが求められています。認証は「誰か」を確認するプロセス、認可は「何を許可するか」を決める仕組みであり、両者の違いを明確に理解しておくことが重要です。

    組織の安全を守るには、基本的なセキュリティ対策の実施が不可欠です。具体的には、攻撃メール訓練の実施、バックアップ管理、システムの更新、強固な認証の導入、アクセス制御とログ分析などが推奨されます。また、インシデント対応チーム(CSIRT)の整備により、問題発生時の迅速な対応が可能となります。

    APIセキュリティの観点からは、OAuthトークンの導入、通信の暗号化と署名、レート制限やスロットリングでの制限、APIゲートウェイが推奨されます。開発段階からリリース・運用後まで脆弱性管理を徹底し、特にユーザへの影響が大きいと考えられるサービスでは第三者機関によるセキュリティ診断も活用することをおすすめします。

    Security Report TOPに戻る
    TOP-更新情報に戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

Linuxサーバーを狙うOpenSSH脆弱性
(CVE-2024-6387)-影響と即時対応策まとめ-

Share
  • CVE-2024-6387は、OpenSSHサーバーに存在する重大な脆弱性です。
  • この脆弱性により、リモートから認証なしに任意のコードを実行できる可能性があります。
  • 影響を受けるのは、glibcベースのLinuxシステム上のOpenSSHサーバーです。
  • 脆弱性は、シグナルハンドラーの競合状態に起因します。
  • Qualys社によって発見され、2024年7月1日に公表されました。
  • 修正バージョンが提供されています。
  • 影響を受けるバージョンは、OpenSSH 8.5p1から9.7p1までです。
  • 対策として、OpenSSHの最新バージョンへのアップデートが推奨されています。

CVE-2024-6387

  • CVE-2024-6387は、シグナルハンドラーの競合状態により発生します。
  • この脆弱性により、リモートから認証なしに任意のコードを実行できる可能性があります。
  • 本脆弱性は、以前に対処されたCVE-2006-5051の再発(リグレッション)と考えられています。

影響を受けるバージョン

  • 影響を受けるのは、glibcベースのLinuxシステム上のOpenSSHサーバーです。
  • 影響を受けるバージョンは、OpenSSH 8.5p1から9.7p1までです。
  • 4.4p1より前のバージョンは、過去の脆弱性(CVE-2006-5051およびCVE-2008-4109)のパッチが適用されていれば影響を受けません。
  • OpenBSDは影響を受けません。
  • Qualys社のテレメトリ情報によれば、インターネットに公開されたホストの約3割(70万台)が脆弱な状態にあると推定されています。

対策方法

  • 利用中のOpenSSHの最新バージョンへのアップデートが推奨されています。詳細については利用中のディストリビューションの最新情報をご確認ください。
  • 暫定の回避策としてデフォルト設定のSSHファイアウォールルールの削除という方法もありますが、DDoS攻撃に無防備になる可能性があるため、アクセス制御を行った上で実施してください。なお、アップデート後はファイアウォールルールを再設定してください。

攻撃の検証状況

  • ASLR有効化済みの32ビットLinux/glibc環境で攻撃が成功することが確認されています。
  • 理論上は64ビット環境でも可能と見られますが、現時点で実証されていません。
  • 脆弱性の概念実証(PoC)コードは存在しますが、実際の攻撃活動は確認されていません。(2024/7/3時点)
  • テスト環境では、PoCを使用してCVE-2024-6387の脆弱性を悪用したリモートコード実行は実現できませんでした。
  • Qualys社はこの脆弱性の実証コードを公開しない方針です。

【関連情報】

  • CVE-2024-6387は、以前に対処されたCVE-2006-5051の再発(リグレッション)と考えられています。
  • OpenBSDは2001年に本脆弱性を防ぐ安全なメカニズムを開発しており、影響を受けません。
  • 脆弱性の深刻度(CVSSv3.1スコア)は8.1「Critical(緊急)」と評価されています。
  • この脆弱性を悪用するには、平均して6時間から8時間程度の連続した接続が必要であり、攻撃の成功率は低いのではないかとの指摘もあります。

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像