AWS の技術ブログ

全3302件

2024/06/17

この投稿はネットアップ合同会社岩井陽太郎氏に、サイバーレジリエンスの解説と AWS における実装ポイントについて寄稿いただいたものです。皆様はサイバーレジリエンスという言葉に聞き覚えはありますか？企業のデジタル化が進む中、ビジネスにおける IT 部門の担う責任は日々重くなってきています。これまではサイバーセキュリティの考え方に則った、被害をどう防いでいくかに焦点を当てた「防御」の考え方に大きく注目が集まっていましたが、際限のない投資が必要なことから「セキュリティ疲れ」とも呼ばれる反動が起きています。そこで昨今では「防御」だけではなく、被災することを前提としてそこからいかに迅速に「回復」・「復旧」するかという「サイバーレジリエンス」という考え方が注目を集めています。本ブログシリーズでは、サイバーレジリエンスについて組織の重要な資産である「データ」の観点でご紹介していきます。第 1 回ブログでは、「サイバーレジリエンス」に関する基礎的な内容を解説します。組織を取り巻く様々な事業継続リスク皆様を取り巻く環境には、ビジネスの継続を困難にする多くのリスクが存在しています。特に日本では、大規模な自然災害のリスクと常に隣り合わせにあります。南海トラフ地震のような予測不可能な災害に備えなければならなかったり、地球温暖化による台風の大型化/強大化も懸念されています。また、昨今猛威を振るうランサムウェア攻撃に対して防御策を講じることや、年々規制が厳しくなっているコンプライアンスや法令違反のリスクへの備えも重要です。これらの事業継続リスクについて、もう少し掘り下げていきます。自然災害リスク自然災害には地震、津波、土砂災害、台風、豪雨、感染症の流行などさまざまな種類があり、どれも大きな脅威です。このような大規模な災害が発生した場合、ビジネスを継続させるためには復旧作業だけでなく、限られた人員での運用や予期せぬ業務にも対応する必要があります。地震を例に挙げて説明します。まず被害として、建物の倒壊、機材の破損などが想定されます。物理的な修復作業はもちろん必要ですが、被災時には予想外の業務が頻繁に発生します。たとえば市役所の場合、地震が発生すると住民に対して罹災証明書を発行するという通常は行わない業務が一時的に必要になります。これらの業務は、被災した社員や職員自身が行わなければならないため、非常に困難な作業となります。サイバー攻撃リスク特に最近では、国内外でサイバー攻撃による被害が増加しており、多くの企業が重大な事業継続リスクとして認識しています。特に近年では、ランサムウェアによる被害が拡大しており、関心が高まっています。かつて、コンピュータウイルスが広まった時代には、「誰でもいいから困らせたい」という愉快犯的な行為が主流でしたが、現在ではダークウェブ上でのランサムウェア攻撃がビジネスとして成立してしまっており、ランサムウェアを使った身代金を要求する犯罪が組織的に行われています。具体的には、ランサムウェアを開発するグループや、攻撃対象となる組織の認証情報を盗むアクセスブローカー、彼らからランサムウェアや有効な認証情報を購入し、実際に攻撃を実行するグループなど、分業体制が確立されています。コンプライアンスの遵守や法令違反のリスク General data Protection Regulation (GDPR) という規制をご存知でしょうか？GDPR は、欧州連合 (European Union: EU) におけるデータ保護に関する規則で、世界で最も厳しいとされており、罰金の金額は増加傾向にあります。このような規制には、ヨーロッパ在住のユーザーに対してサービスを提供している場合や、現地法人を持ち、現地の従業員が働いている場合など、本社が海外にあったとしてもヨーロッパに関連する事業に対して適用されるという注意点があります。実際、2022 年には日本の大手システムインテグレーターが現地法人によるデータ漏洩の違反で罰金を支払うケースがありました。また、日本国内でもデータに関する規制は厳しくなっており、大きく二つの法改正が行われています。一つは個人情報保護法の改正です。2020 年に改正され、法人による報告や通知の義務化、措置命令違反や不正流用に対する罰則が強化されました (改正前は 30 万円以下、改正後は 1 億円以下) 。もう一つは、2022 年に改正された電子帳票保存法です。この改正により、電子取引に関する情報を紙ではなく電磁気的に記録することが義務化されました。データの活用が進む中で、プライバシーやコンプライアンスに関する規制もより厳しくなっています。このような規制の改正は、ビジネスにおいて金銭的および社会的な大きなリスクとなる可能性があるため、注意が必要です。そしてサイバーレジリエンスの考え方へ企業は、さまざまな事業継続リスクに対して対策を策定する必要があります。しかし、攻撃者にとっては一度でも攻撃が成功すればよく、防御側は常に守り続けなければなりません。そのため、際限のない投資が必要となるのと同時に、コストをかけても効果が保証されるわけではありません。また、そのような投資は事業利益を直接的に生み出すわけではなく、被害が起こらなければ投資対効果を定量的に示すことが難しい場合もあるかもしれません。このような状況から、組織は慢性的な「セキュリティ疲れ」に悩まされることが増えており、対応を後回しにすることもあります。数年前より欧米を中心に、サイバーレジリエンスという「復元力」に焦点を当てたアプローチが注目されています。様々なリスクによる被害を受けないよう有効な防御策を講じることは重要ですが、サイバーレジリエンスの考え方は、「被災することを前提として、そこからいかに迅速に回復・復旧するか」に焦点を当てます。こうしたシステムを守るための考え方について、アメリカ国立標準技術研究所 (National Institute of Standards and Technology: NIST) は 2014 年に「レジリエンス」の考え方を盛り込んだ、Cybersecurity Framework (CSF) の 1.0 版を公開しました。この CSF では、以下の 5 つの機能をフレームワークの「コア」として定義しています。 Identify [識別]: リスクの特定と評価 Protect [防御]: 適切な保護対策の実施 Detect [検知]: セキュリティイベントの発生の識別 Response [対応]: 関係者間調整や分析、影響緩和や改善の実施 Recover [復旧]: システムや資産の復旧これら 5 つの機能を分類すると、「識別」と「防御」は防御力に焦点を当てた従来の「サイバーセキュリティ」に関する部分にあたるのに対し、後半の「検知」「対応」「復旧」では万が一被災した場合に変化する状況に適応しながら迅速にシステムを復旧させる「復元力：レジリエンス」に焦点を当てた機能という事が読み取れます。サイバーレジリエンスの手法と取り組み方 CSF の内容は汎用的なフレームワークであり、サイバーレジリエンスの概念や体制を包括的にまとめています。さらに、個別のテーマに応じた具体的な手法や手順をまとめている「 SP800-160 Vol.2 : Developing Cyber-Resilient Systems: A Systems Security Engineering Approach 」 (以下、ガイドライン) があり、「サイバーレジリエンス」に関連する取り組みの「目的」「目標」「手法」について解説しています。図 1: サイバーレジリエンスの「目的」「目標」「手法」これら手法の定義はやや抽象的な表現が用いられていますが、このガイドラインでは、より実装に近い「取り組み方」についても提案しています。各手法の詳細な解説は省略しますが、データの観点での「復元力」に関連する以下の 3 つの手法について掘り下げてみます。権限の制限データの外部からの保護機能が充実していても、ユーザーにおける対策が不十分だと、リスクを未然に防ぐことはできません。具体的には「最小権限の原則」に従い、特権ユーザーである「root」や「Administrator」を共有せず、役割に応じて必要最小限の特権を個々のユーザーに与える「ロールベースのアクセス制御」や、場所や時間帯によるアクセス制限、パスワード漏えい・詐取による不正ログインに対して耐性を高めるための多要素認証 (Multi-Factor Authentication: MFA) などが挙げられます。また、管理者権限を持つ悪意のあるユーザーや偶発的な誤操作によるリスクを防ぐためには、「複数管理者認証機能」など、特定の操作に他の管理者の承認が必要な仕組みも効果的です。分析的な監視最近では、データを破壊する攻撃だけでなく、データの窃盗も頻繁に発生しています。このような被害を防ぐ手段としては、監査ログの取得と保全、複数の事象からの合的な攻撃検出、そして異常な振る舞いの検知などが挙げられます。監査ログは、攻撃の検出や原因究明だけでなく、被害範囲の特定とピンポイントな復元のためにも重要です。また、内部者によるデータの持ち出しなどの操作は、気づかれずに行われることが多いです。通常と異なるデータへのアクセスの仕方を検出してアクセスを自動的に遮断し、管理者に通報すると同時に、その時点でのデータバックアップを即座に取得するなどの仕組みも効果的です。冗長化最後に、データの観点でのレジリエンスにおいて最もイメージしやすく、非常に重要となってくるのがこの「冗長化」ではないでしょうか。 NIST が公開してるガイドラインには、「冗長化」への取り組み方が３つ示されています。余剰容量（surplus capacity）複製（replication）保護されたバックアップとリストア（protected backup and restore）具体的には、システムにおける性能・容量を余剰容量として換算し、安全マージンを施した設計・設定で運用したり、クラウドを活用した一時的な拡張によるクラウドバースト、サーバーの冗長化、サービス提供ロケーション（アベイラビリティゾーン）の冗長化、データのバックアップなどが当てはまります。特に重要な経営資源となる「データ」は、一度失うと復旧は容易ではなく影響が大きなものとなるため、バックアップつまりは「データの冗長化」が必要になります。データの冗長化、言い換えると、データのバックアップ取得の必要性については、AWS が公開しているデータバックアップとは何ですか?  で整理されていますので引用したいと思います。データのバックアップが重要なのはなぜですか? あらゆる組織はシステムが常に想定どおりに動作することを望んでいますが、分離されたシステムコンポーネントでは障害が発生する可能性があり、実際に障害が発生しています。まれにではありますが、システム全体での障害が発生する可能性もあります。データバックアップとは、障害が発生したときに復元できるように、組織のデータをコピーするインフラストラクチャ、テクノロジー、プロセスをいいます。これには、適切なデータバックアップ戦略とソリューションを含むディザスタリカバリ計画が含まれます。効果的なデータバックアップにより、災害時におけるデータとシステムの損失を防ぎます。これは、想定外の状況であっても、ビジネスの継続性と中断のないサービスを実現するのに役立ちます。重要なビジネスシステムは、ビジネスに対する影響を最小限に抑えながら、運用を迅速に開始できます。適切なデータのバックアップと復旧がなければ、システムは数時間、数日、または数週間にわたってオフラインになる可能性があります。状況によっては、エキスパートのデジタルフォレンジックの助けを借りても、まったく復旧できない場合があります。データの冗長化（バックアップ）実践データの冗長化（バックアップ）として良く知られた考え方として、「3-2-1 ルール」があります。この 3-2-1 ルールについても AWS が公開しているデータバックアップとは何ですか? から引用してご紹介します。このルールは、どのような種類の障害が発生しても最大限の復旧可能性を得るためには、2 つの異なる種類のメディアに少なくとも 3 つのデータコピーが必要であり、1 つはオフサイトコピーである必要があるという旨を規定するものです。多くの組織は、3-2-1 ルールに従うことを選択しています。バックアップを取得する際には、更に「バックアップしたデータの保護」についても留意すべきです。昨今のランサムウェア攻撃では、オリジナルデータを暗号化・改ざん・削除するだけでなく、バックアップからの復元を妨げるためにバックアップデータも破壊する事例も登場しています。特権ユーザーによる悪意のある操作でバックアップデータが破壊された事例もあり、削除できない保護されたバックアップ（Immutable Backup）を取得する必要があります。また、バックアップデータからの復旧の「しやすさ」についても考慮しておく必要があります。特にランサムウェア攻撃からのデータ復旧では、「最新のバックアップデータを利用して、すべてのデータをリストアする」といった単純なものではなく、「暗号化されたファイルやフォルダはなにか」「どのユーザーや経路から攻撃されたのか」といった解析を行うデジタルフォレンジックをシステム・サービスの復旧と並行で行う必要があります。このため「暗号化されてしまったデータを攻撃される前のバックアップデータを利用して、別の安全な環境にリストアすることでシステム・サービスを復旧する」といった復旧のしやすさが重要になります。 AWS でどのように実装するか皆様が抱えている事業継続のリスクに応じ、サイバーレジリエンスの考え方に基づきシステムを迅速に復旧させる仕組みを実装していかなければなりません。現在、多くのお客様がオンプレミスとクラウド両方の環境をお持ちであることを考慮し、まずは変更や機能の追加が迅速かつ容易なクラウド環境から取り組み始めてはいかがでしょうか？クラウドサービスを利用する上で事業者 (AWS) とお客様の間で様々な責任を共有することになるため、利用者は自身の責任範疇を明確に理解する必要があります。AWS では、一般的なクラウド上でのベストプラクティスを述べた AWS Well-Architected Framework を公開しています。その中でも、レジリエンスに関連する「信頼性の柱」について説明している回復に関する責任共有モデルを参照するとよいのではないでしょうか。クラウドの回復性：サービスを実行するインフラストラクチャの回復性に責任を持つ AWS と、クラウド内での回復性：利用するサービスごとに適切な設定を実行する責任を持つお客様でお互いの責任を理解し、ベストプラクティスに則った信頼性の高いインフラの構築にお役立てください。まとめこれまで IT の世界では、いかに脅威や災害からシステムを「防御」するかについての対策が取られてきました。しかし、サイバー攻撃手法の多様化や災害大国という立地から、すべての被害を防ぎきることが難しくなりつつあります。「防御」だけでなく、被害からいかに迅速に「復旧」するか、つまり「サイバーレジリエンス」を考えることが重要です。NIST が発表している CSF や SP-800 シリーズといったドキュメントを読み解き、どのようにデータの「復元力」を実現するか本ブログシリーズを通してご紹介していきます。

AWS の技術ブログ

コンテンツ