2021年12月09日

「ENISA Threat Landscape 2021」における推奨事項の参考訳

「ENISA Threat Landscape 2021」を紹介する記事

「海の向こうの“セキュリティ”」第183回
コロナ禍で増えた偽情報や「悪意のない脅威」への対応として気を付けたいこと
https://internet.watch.impress.co.jp/docs/column/security/1372358.html

もご参照ください。

欧州ネットワーク情報セキュリティ機関(ENISA:The European Union Agency for Cybersecurity)が、2020年4月から2021年7月までのサイバーセキュリティの脅威状況をまとめた年次報告書「ENISA Threat Landscape 2021」において、対象期間中に顕著だった脅威として挙げた9つのうち、以下の8つについて対処のための推奨事項などが紹介されています。

  • ランサムウェア(Ransomware)
  • マルウェア(Malware)
  • クリプトジャッキング(Cryptojacking)
  • 電子メール関連の脅威(E-mail related threats)
  • データに対する脅威(Threats against data)
  • 可用性と完全性に対する脅威(Threats against availability and integrity)
  • 偽情報 - 誤報(Disinformation - misinformation)
  • 悪意のない脅威(Non-malicious threats)
ENISAによる推奨事項は、今回の報告書の執筆に多くの方が関与しているためと思われますが、表現形式(文体)が揃っていませんし、対象者の異なる項目が整理されないまま混在しているため、全体像を把握しづらいと感じる方も少なくないでしょう。それでも、様々な専門家らによる見方や「ある考え方」を列挙したものとして十分に参考になるところがあるはずです。とにかく、あくまで参考資料の1つとして使うべきものであり、何らかの標準規格や義務となるものではないことにご注意ください。

以下は各脅威に対する「RECOMMENDATIONS」を翻訳したものです。あくまで参考訳にすぎませんので正確を期する場合は必ず原文を確認してください。

ランサムウェア

  • セキュアで冗長性のあるバックアップ戦略の実施。
  • IDとアクセス管理の実施と監査(最小特権と職務分離)。
  • ユーザ(特権ユーザを含む)のトレーニングと意識向上。
  • 開発環境と本番環境の分離。
  • インシデントに関する当局や業界との情報共有。
  • 既知のランサムウェアサイトへのアクセスの制限。
  • 権限を付与されたデバイス、ユーザ、およびプロセスに対して、IDおよび認証情報(credentials)を発行、管理、検証、無効化および監査を行うべきである。
  • 最小権限と職務分離の原則を取り入れた、アクセス許可と権限付与を管理すべきである。
  • 開発環境と本番環境の分離。※訳註:上記項目と重複しているので誤記と思われる。
  • ランサムウェア対応・復旧計画を定期的にテストし、進化するランサムウェアの脅威に関して、リスクと対応の想定とプロセスが最新であることを確認すべきである。
  • 既知のランサムウェアサイトへのアクセスをブロックするセキュリティ製品またはサービスの使用。
  • CISAが開発したITおよびICS(industrial control system、産業用制御システム)ネットワークを対象としたツールであるRRA(Ransomware Readiness Assessment)を実行し、様々なレベルのランサムウェアの脅威への備えに対するセキュリティを評価する。
  • 攻撃や攻撃の試みを当局に報告し、その拡散を抑制する。
  • システムの監視による感染の早期確認。
  • 最近のランサムウェアの動向、開発状況、防止策の提案を常に把握する。

マルウェア

  • 電子メール、ネットワーク、Web、アプリケーションシステムを含む、全ての適用可能なプラットフォーム(サーバー、ネットワークインフラ、パーソナルコンピュータ、モバイルデバイスなど)の入出力チャネルに対してマルウェア検知を実施。
  • SSL/TLSトラフィックを検査し、Webサイト、電子メール通信、モバイルアプリで送受信される内容をファイアウォールで復号できるようにする。
  • マルウェアの検知機能(インテリジェンスによるスレットハンティング)とセキュリティインシデント管理の間のインターフェースを確立し、効率的な対応能力を確立する。
  • マルウェア情報の共有やマルウェアの緩和のためにマルウェア解析に使えるツールを使用する(MISPなど)。
  • 感染発生時に従うべきプロセスを定めたセキュリティポリシーを策定する。
  • 様々なセキュリティツールの機能を理解し、新しいセキュリティソリューションを開発する。ギャップを特定し、多層防御の原則を適用する。
  • 悪意のある電子メールに対するメールフィルタリング(またはスパムフィルタリング)を使って実行可能な添付ファイルを削除する。
  • アンチウイルスのテスト結果を定期的に監視する。
  • コンテナインフラにパッチ管理を使用する。
  • SIEM(Security Incident and Event Management)ソリューションを使ったログ監視を活用する。具体的なログのソースとしては、アンチウイルスの警告、EDR(Endpoint Detection and Response)、プロキシサーバーのログ、WindowsのEventおよびSysmonログ、IDS(Intrusion Detection System)のログなどが挙げられる。
  • PowerShell機能へのアクセスを無効化または削減。

クリプトジャッキング

  • ユーザのデバイスのバッテリー使用量を監視し、CPU使用量が不審な急増を見せている場合は、ファイルベースのマイナーの存在をスキャンする。
  • 一般的なクリプトマイニングのプロトコルのWebフィルタリング、および広く使われているクリプトマイニングのIPプールのIPアドレスとドメインのブラックリスト化を実施する。
  • ネットワークの異常を監視し、マイニングプロトコルをブロックする。
  • アンチウイルスプログラムやクリプトマイニングをブロックするブラウザのプラグインを使ったエンドポイント保護を導入する。
  • 定期的にセキュリティ監査を実施し、ネットワークの異常を検知する。
  • 新たに生まれる脅威や脆弱性から保護するために、強固な脆弱性およびパッチの管理を実施する。
  • よく知られているエクスプロイトに対するパッチ適用や修正を行なう。
  • ホワイトリストを使って、未知の実行ファイルのエンドポイントでの実行を防止する。
  • 許可リストを使って、既知の実行ファイルのみエンドポイントでの実行を許可する。
  • 一般的なクリプトマイニングの実行ファイルを監視およびブロックする。
  • ユーザのクリプトジャッキングに対する意識を高めるために投資する。セキュアなブラウジング行動については特に。
  • セキュリティ意識向上トレーニングの中で、クリプトマイニングについて議論する。

電子メール関連の脅威

  • 疑わしいリンクや添付ファイルの見分け方と報告の仕方について定期的にユーザトレーニングを実施する。
  • 電子メールゲートウェイにスパムフィルターを導入し、シグネチャとルールを常に更新する。可能な限り、フィルター(アンチスパム、アンチマルウェア、ポリシーベースのフィルタリング)の自動メンテナンス機能を備えたセキュアな電子メールゲートウェイを使用する。
  • 従業員の受信箱にルアーが届く頻度や可能性を減らすために、電子メールゲートウェイにセキュリティコントロールを導入する。
  • いかなるセキュリティ侵害の影響も抑えられるように、知っておくべき(need-to-know)アクセスポリシーを導入する。
  • サイバーセキュリティの脅威に関する敵対者の戦術や技術についてMITRE ATT&CKフレームワークを参考にする。
  • 組織外から送信された電子メールは受信前に自動的にマーク付けされるように。
  • アカウントに多要素認証(MFA)を導入する。
  • 疑わしい悪意のあるドメインの存続期間とその所有者を確認する。存続期間が1年以内の場合は詐欺の可能性がある。
  • 可能な限り、機械学習技術を用いてリアルタイムでフィッシングサイトを識別するセキュリティソリューションを適用する。
  • メールクライアントにおいて、コードの自動実行、マクロ、画像データのレンダリング、メールリンクのプリロードを無効化して(クライアントを)頻繁に更新する。
  • スパムメールを減らすための標準規格のいずれかを導入する。
  • 可能な限り、重要な金融取引または機密情報のやりとりには、デジタル署名または暗号化を用いたセキュアな電子メール通信を導入する。
  • 可能な限り、ネットワークレベルで受信メールおよび送信メールの両方に対して不正や異常の検知を実施する。
  • 電子メールの送信元に絶対の自信を持てない場合は、ランダムなリンクをクリックしたり、添付ファイルをダウンロードしたりしない。
  • 閲覧するWebサイト、特に細心の注意を要するWebサイト(銀行のWebサイトなど)の場合は、ドメイン名にタイプミスがないか確認する。脅威主体は通常、正規のドメインに似た偽のドメインを登録し、ターゲットを「フィッシングする(釣る)」ために使用する。HTTPS接続を期待するだけでは十分ではない。
  • 全てのオンラインサービスに強力且つ固有のパスワードを使用する。様々なサービスで同じパスワードを使い回すことは、深刻なセキュリティ問題であり、常に避けるべきである。全てのオンラインサービスに強力且つ固有の認証情報を使用することで、アカウントが乗っ取られる可能性のあるリスクを、影響を受けるサービスのみに限定することができる。パスワード管理ソフトウェアを使用すれば、一連のパスワード全体の管理が容易になる。
  • 攻撃者が悪用できないように、問い合わせや登録、購読、フィードバックの入力フォームが自分たちのWebサイト上でどのように機能するかを確認し、必要に応じて検証ルールを追加する。
  • 不要な添付ファイル、悪意のある内容を含む電子メール、スパム、不要なネットワークトラフィックを検出するコンテンツフィルタリングを導入する。
  • 知らない送信者からの電子メールやSMSメッセージに含まれる新しいリンクには反応しないようにし、且つ、何よりも、そのようなリンクをたどる際に認証情報を入力してはいけない。

データに対する脅威

  • サイバーセキュリティ意識向上計画を策定および維持する。ソーシャル・エンジニアリングやフィッシング・キャンペーンを特定するためのトレーニングやシミュレーション・シナリオを従業員に提供する。
  • 知る必要がある人にだけ知らせる(need-to-know)原則の下、ユーザのアクセス権を制限する。従業員以外の者のアクセス権を無効化する。
  • インシデント対応チームを設置・維持し、且つインシデント対応計画を頻繁に評価する。
  • 機密性の高い情報/個人情報を発見・分類し、転送中および保存中のそのようなデータを暗号化する手段を講じる。つまり、データ損失防止機能を導入する。
  • 検知、警告ツール、およびデータ侵害の抑制と対応の能力に関する投資を増やす。
  • 強力なパスワード(パスワード管理)と多要素認証(MFA)の使用を強制する強力なポリシーを策定・維持する。
  • オンプレミスおよびオフプレミスのリソースの両方に対するセキュリティを提供するために、最小権限方式を採用したモデルを検討する(例:ゼロトラスト)。
  • ガバナンス、リスク管理、およびコンプライアンスチームと連携するためのポリシーと計画に投資し、且つそれらを策定する。
  • データをセキュアなIT資産にのみ保存する。
  • 担当者を定期的に教育・訓練する。
  • 脆弱性スキャン、マルウェアスキャン、データ損失防止(DLP)ツールなど、データ漏洩の可能性を回避するためのテクノロジーツールを使用する。データとポータブルシステムとデバイスの暗号化、およびセキュアゲートウェイを導入する。
  • データ侵害が発生した場合、事業継続計画(BCP)が重要となる。この計画では、保存されているデータの種類、その場所、データセキュリティと復旧対策を実施する際に発生する可能性のある法的責任の概要を示している。BCPには効果的なインシデント対応が含まれており、このようなインシデントによる損害について対処・管理・是正することを目的としている。
  • セキュリティ計画を強化するために企業内で「スレットハンティング」を実施する。スレットハンティングはセキュリティオペレーションセンター(SOC)チームの熟練したメンバーによって行われ、積極的に(先を見越して)脆弱性を特定し、侵害を防止する。
  • 速度ベース(velocity-based)のルールのようなポリシーは、特にペイメントカード取引におけるID詐欺を軽減するために使用できる。有効な取引のマシンデータは最適なポリシー定義のための十分な情報を提供することができる。
  • シングルサインオン(SSO)の認証手段が利用可能な場合、ユーザは同じデジタル認証情報のセットで複数のアプリケーションにアクセスすることができる。SSOを使用することで、ユーザアカウントおよび保存された認証情報の数を最小限にすることが強く推奨される。
  • 電子メールで送られてきたURLやランダムにアクセスしたURLは、そのIPアドレス、そのIPに結びついたASN、ドメインの所有者、およびこのドメインと他のドメインとの関連性に基づいて、それ以上の手順を踏む前に、まずチェックすべきである。
  • クラウドサービスを採用している組織は、強力なクラウドセキュリティオペレーションを行うべきであり、顧客の個人情報を保護するために、オンプレミスのストレージ、プライベートクラウドのストレージ、パブリッククラウドのストレージを同時に使用するアーキテクチャを選ぶべきである。
  • ハッキングを防ぐため、機密データにはTLS 1.3(ephemeral(一時的な)鍵を使用)などの強力で最新の暗号化方式を使用する。
  • 全てのID文書およびそのコピー(物理的またはデジタルなもの)を無権限アクセスから適切に保護する。
  • ID情報は未承諾の受信者に開示すべきでなく、電話、電子メール、または対面での要求に答えるべきではない。
  • 不要な添付ファイル、悪意のあるコンテンツを含むメール、スパム、不要なネットワークトラフィックを排除するためにコンテンツフィルタリングを導入・使用する。
  • データ損失防止(DLP)ソリューションを使用する。

可用性と完全性に対する脅威

  • サービス妨害対応計画は、レジリエンスが優先される組織にとって不可欠なものであり、システムのチェックリスト、対応チーム、効率的なコミュニケーションとエスカレーション手順を統合すべきである。
  • セキュリティプロセスは、システムおよびネットワークの進化とライフサイクルに追従し、適応する継続的な活動であるべきである。
  • 緩和の取り組みを拡大・強化するためには関連組織間の連携と調整が重要である。
  • オンプレミス型ソリューション、DDoSスクラビングサービス、またはハイブリッド型ソリューションを使用したDDoS防御を導入する。
  • ネットワークファイアウォールとWebアプリケーションファイアウォールの両方を使用する。前者は、コンテンツデリバリネットワーク (CDN)、ロードバランサー、拡張可能なリソースなど、ピーク時のトラフィックを軽減するアプローチと組み合わせることができる。後者は、DDoSがインジェクションまたはXSSに基づいている場合に特に有効である。
  • マルウェアの感染を抑制するためにアンチウイルスソリューションを使用する。
  • ネットワークベースの侵入検知システムを使用する。
  • パッチを速やかに適用する。多くの従業員が個人所有のマシンを業務に使用している場合は特に。組織は、システムアップデートの優先度を高くし、リモートでユーザに配信すべきである。
  • トラフィックプロファイリングとトラフィックフィルタリングは、DDoS攻撃の指標となる異常なトラフィックパターンの兆候を早期に警告するのに役立つかもしれない。
  • 異常なトラフィックフローを検知してトラフィックをネットワーク外にリダイレクトするDDoS軽減サービスに加え、受信トラフィック量を制限するレートリミッターを使用する。
  • WebベースのAPIを保護し、関連する脆弱性を監視する。
  • DNSを要塞化する、またはマネージドDNSサービスも検討する。キャッシュポイズニングや同様のエクスプロイトはDNSSECの使用によって防ぐことができるが、DNSSECの仕様をサポートするマネージドDNSベンダを使用するとなお良い。
  • 複数のプラットフォームにわたる検知、調査、および対応能力を組み合わせたマルチレイヤーのソリューションを検討する。
  • 進化する脅威環境にセキュリティ態勢を適応させるプロアクティブなアプローチに基づいて、脅威インテリジェンスプログラムを構築する。
  • 能力開発と備えを強化するためにスタッフのトレーニングとサイバーセキュリティ演習を利用する。
Webベースの攻撃に対する緩和策として挙げられているのは以下の通り
  • 悪意のあるリクエストを識別してフィルタリングするためにWebアプリケーションファイアウォール(WAF)を設置する。新たに発見された脆弱性からシステムを保護するために、WAFは常に更新されていなければならない。
  • インジェクションベースの攻撃から守るためにコードベースを強化する(例:入力サニタイズ、パラメータ化されたステートメント)。
  • ゼロデイ攻撃を避けるためにソフトウェアを速やかに更新する。
  • Webサーバを適切に設定・堅牢化し、インターネットに公開されている全てのサーバに定期的にパッチを適用する。
  • 攻撃ツール、脆弱性スキャナ、侵入テストサービスを使って、セキュリティ強化の効果を継続的に検証する。
  • ログを有効にし、そのログを検査する。

偽情報 - 誤報

緩和策には技術的な領域と非技術的な領域がある。一方では、トレーニングや意識向上、ファクトチェックやデバンキング(debunking、偽りを暴く行為)、規制、そしてコミュニケーションを対象とした、手作業や人力によるアプローチが緩和策となる。その一方で、ソーシャルネットワークを通じた誤報/偽情報の拡散を抑制するための技術的な解決策も重要である。また、誤報/偽情報攻撃の影響をさらに抑えるためには全ての当事者の協力が重要である。

一般的に、誤報や偽情報のキャンペーンを緩和するためには以下のようなアプローチが考えられる。

  • トレーニングと意識向上: 偽情報攻撃に対処し、また更にあらゆる電子メールやレポートを評価するために従業員に備えさせるプロセスである。これに関連して、ワクチンのようなアプローチに従うプレバンキング(prebunking)は、少量の誤報/偽情報にユーザをさらすことで、後に誤報/偽情報に対処できるように備えさせることを目的としている。また、ゲーミフィケーションに着目し、ソーシャルメディアのフィードをシミュレーションすることで、ユーザに本物のニュースとフェイクニュースの見分け方を教えるアプローチもある。例えば、オンラインゲーム「Go Viral!」はCOVID-19にまつわる一般的な誤報をプレバンク(prebunk)することを目的としている。
  • 誤報/偽情報の識別: 偽コンテンツを識別したり、コンテンツに適切にアクセスしたりするためのガイドラインが登場している。例えば、出典、著者、相互参照、引用データ、日付を調べることが挙げられている。
  • ファクトチェックと偽りのストーリーのデバンキング(Debunking False Stories): 誤報や偽情報の影響を減らすために非営利団体と政府機関の両方によって多くの取り組みが行われている。これらの関係者は誤った情報やフェイクニュースを掲載した出版物やコンテンツをデバンキングすることを目的としている。COVID-19にまつわるインフォデミック(infodemic、根拠のない不確かな情報が伝染病のように広まって現実社会に悪影響を及ぼす現象)を阻止するために多くの取り組みが行われてきている。
  • 規制: 新たな規制(提案中のECデジタルサービス法など)や、ソーシャルネットワークを含むフェイクニュースを拡散するサイトを処罰する動きが進められている。GDPR(General Data Protection Regulation、一般データ保護規則)の文脈では、ターゲット広告を可能にする情報へのアクセスを制限することが可能である。したがって、GDPRは、フェイクニュースを広めるためのツールでもあるオンラインターゲット広告による個人データの処理を規制することで誤報対策に役立つことができる。つまり、GDPRは、オンラインターゲット広告を規制することで、間接的に、より広いやり方で誤報の制限にも貢献できるかもしれないのである。偽情報に関する実施規範(Code of Practice)は、産業界の支援を受けて偽情報と戦うための自主規制基準を提供している。EUは先日「ハイブリッドな脅威への対抗に関する2016年の共同枠組み(Joint Framework)とハイブリッドな脅威に対処するためのレジリエンスの向上と能力の強化に関する2018年の共同コミュニケーション(Joint Communication)の実施」に関する第5回進捗報告書(Fifth Progress Report)を発表した。報告書では、自由で公正な選挙を守る必要性、戦略的コミュニケーションの役割とハイブリッド脅威に対抗するための卓越した研究拠点(centre of excellence)、各国間の協力の重要性、急進化や過激主義に対するレジリエンスについて述べられている。
  • 戦略的で透明性のあるコミュニケーション: 事実に基づいたものであり、政治的なコミュニケーションとは別のものである。
  • 技術的な対抗策
    • 検索エンジンのアルゴリズムの書き換え
      • ソーシャルネットワークの検知と緩和:
        1. 偽アカウント(重複した情報や冗長な情報を投稿するアカウントなど)の停止
        2. 偽ニュースをフィルタリングしてフラグを立てる仕組み
        3. 自動活動(ボットなど)の削減
        4. オンライン・アプローチに基づくフェイクニュース検出のための人工知能ツールおよびプラットフォーム
        5. 大規模な偽情報の拡散を特定するためのデータサイエンス/ビッグデータの可視化
        6. 一般市民を対象としたファクトチェッカーを搭載したモバイルアプリおよびチャットボット
        7. 一般市民を対象としたウェブブラウザの拡張機能
        8. デジタルメディア情報リテラシーのプラットフォームおよびツール
    • 広告による啓発活動
    • 信憑性評価、疑わしい行動に対するフラグ立て
    • デジタル電子透かし(ビジュアルコンテンツへのタグ付け)
    • センチメントトラッキング(sentiment tracking)とダークウェブモニタリングを中心とした保護戦略の策定

悪意のない脅威

  • 従来のセキュリティに物理的な保護と災害復旧を加えた、セキュリティに対する全体的なアプローチを採用しなければならない。
  • クラウドサービスだけでなく、悪意のない脅威を考慮したリスク管理プロセスを採用すること。
  • 適切な資産管理とともにシャドーIT(特にシャドーIoT)を回避すること。
  • エラーや設定ミスをタイムリーに発見するための継続的な監視とテスト。
  • 組織的ポリシー: 基本的なサイバー対策が不十分なことが多い一方で、攻撃はより巧妙になり、サプライチェーンや人的要因への依存度が高まっている。後者の場合、AI(例:ディープフェイク)を利用した攻撃がヒューマンエラーを引き起こす可能性があり、完全に技術的な方法で防ぐことは非常に困難である。したがって、ヒューマンエラーを軽減するためには、強固な組織的ポリシーが必要となる。
  • データとセキュリティに対するガバナンスベースのアプローチを採用し、データを徹底的に検討し、それに従うことができるようにすること。
  • 脆弱性に対処するためのパッチ管理計画: 適切な計画とは、全てにパッチを当てることを要求するのではなく、必要なものにパッチを当てることを意味し、最終的には、例えば、リスク管理プロセスから得られる優先順位を使用すること。
  • パッチ管理のより広い定義を採用するなら、アップデートを受け取る組織だけでなく、アップデートを推進する組織(ソフトウェアおよびハードウェアの製造者など)にも言及すべきである。IoTの脆弱性は何年も前から存在しているケースが多く、誰が実際にパッチを発行すべきかを理解するのは困難である。
  • アップデートはセキュアな方法で配信されるべきである(例:Tesla Model Xのコード署名の欠如)。
  • パッチ管理ではサプライチェーンのリスクを考慮しなければならない。
  • あらゆるタイプのユーザに対するトレーニングと意識向上。適切なトレーニングを受けた開発者は、最新の言語やフレームワークを活用して、より多くのセキュリティ保証を与えながら、製品に多くのセキュリティおよび安全対策を導入することができる。これは、メモリの安全性に関する問題のような長年の課題を抱えていないセキュアなIoTデバイスを開発するためにも極めて重要である。管理者は、デフォルトでセキュリティが確保されているソリューションを利用して、自らの活動におけるセキュリティ(およびコンプライアンス)の側面についてトレーニングを受けるべきである。最後に、エンドユーザが、例えばインシデントの初期兆候を認識し、適切な瞬間に適切な選択ができるようになるためにはトレーニングと啓発が不可欠である。
  • 自然現象に対してより強固な物理的インフラのエンジニアリング、および予期せぬ出来事や(何らかの)不足に際しても事業継続を保証するユーティリティの適切な管理。
  • 全てのものが悪意のあるものであり、信頼できないものであると考える、ゼロトラストのセキュリティアプローチ。このアプローチでは、場所や所有者による暗黙的な資産の信頼から、「アイデンティティは新たな境界線である」とのモットーに従って認証と認可が明示的に与えられる動的なアプローチへと移行する。
  • サイバーセキュリティと物理的セキュリティを統合しなければならないとの、経営者レベルの意識の向上。物理的な攻撃が増加しているにもかかわらず、企業のリーダーは自分たちの会社が物理的な脅威のターゲットになる可能性があることを信じようとしない。
  • 復旧計画とバックアップはシステムのレジリエンス(回復力)を高めるための基本である。
  • 物理的な侵害は攻撃を助長する可能性がある。例えば、物理的なアクセスコントロールの脆弱性、追尾者(tailgater)、無人デバイスは敵対者が攻撃を実行する際に役立つ可能性がある。
  • 内部設備(暖房、換気、空調)のエラーや誤作動は、火災、湿度、不安定な電源供給などによりITインフラにダメージを与える可能性がある。
  • 気候変動はシステムの可用性と耐障害性に新たな課題をもたらしている。洪水、火災、地震の発生率は増加しており、全てのインフラに与える影響は指数関数的に大きくなっている。リスク評価、災害復旧技術、人材育成が不可欠である。
posted by yamaga at 12:08| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

「海の向こうの“セキュリティ”」第183回公開

今月分が公開されました。

コロナ禍で増えた偽情報や「悪意のない脅威」への対応として気を付けたいこと
ENISAが年次報告書「ENISA Threat Landscape 2021」を公開
https://internet.watch.impress.co.jp/docs/column/security/1372358.html
posted by yamaga at 12:04| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年11月11日

「海の向こうの“セキュリティ”」第182回公開

今月分が公開されました。

Amazon、Google、Microsoftらが発表した「信頼できるクラウドの原則」とは
https://internet.watch.impress.co.jp/docs/column/security/1364882.html
posted by yamaga at 06:09| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年10月21日

MIT Kerberos5 1.19.2 で LibreSSL 3.4.1 を使うためのパッチ

MIT Kerberos5 1.19.2LibreSSL 3.4.1 を使うためには以下のパッチをあてれば良さそう。
diff -ru ../krb5-1.19.2.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
--- ../krb5-1.19.2.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-07-23 00:50:07.000000000 +0900
+++ ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-07-29 07:50:37.984361221 +0900
@@ -185,7 +185,7 @@
(*_x509_pp) = PKCS7_cert_from_signer_info(_p7,_si)
#endif

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER)

/* 1.1 standardizes constructor and destructor names, renaming
* EVP_MD_CTX_{create,destroy} and deprecating ASN1_STRING_data. */
posted by yamaga at 07:44| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年10月07日

「海の向こうの“セキュリティ”」第181回公開

今月分が公開されました。連載開始から丸15年が過ぎ、今回で16年目に入りました。今後とも宜しくお願い致します。

マネージドサービスプロバイダーを踏み台にする攻撃、利用企業がリスクを減らすためにできることは?
https://internet.watch.impress.co.jp/docs/column/security/1356460.html
posted by yamaga at 06:10| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年09月17日

MacPorts の ClamAV 0.104.0 以降で experimental features を有効にしてビルドする方法

先日リリースされた ClamAV 0.104.0 からビルド方法が従来の GNU Autotools(configure スクリプト)から、CMake に変更されました。

Building ClamAV with CMake (v0.104 and newer)
https://docs.clamav.net/manual/Installing/Installing-from-source-Unix.html

従来は experimental features を有効にしてビルドする場合は configure スクリプトに --enable-experimental を付ければよかったのですが、CMake の場合は -D ENABLE_EXPERIMENTAL=ON を付ける必要があります。

そこで、パッケージ管理システムとして MacPorts を利用している場合は、Portfile
--- Portfile.ORG	2021-09-17 05:59:32.000000000 +0900
+++ Portfile 2021-09-17 18:41:21.000000000 +0900
@@ -62,6 +62,10 @@
configure.args-append -D OPTIMIZE=OFF
}

+variant exp description {build with experimental features} {
+ configure.args-append -D ENABLE_EXPERIMENTAL=ON
+ }
+
variant clamav_milter description {build with libmilter support} {
depends_lib-append port:libmilter
configure.args-append -D ENABLE_MILTER=ON
のようなパッチを当て、以下のように実行してビルド&インストールします。
sudo port install clamav +exp
posted by yamaga at 19:52| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年09月15日

Vivaldi で PWA(Progressive Web Apps)をインストールする方法

Chromium ベースの Web ブラウザ Vivaldi は標準では PWA(Progressive Web Apps)をインストールできないようですが、以下のようにすればインストールできます。
2021年10月7日追記
Vivaldi 4.3 からは標準でサポートされるようになりました。

(1) vivaldi://experiments/ を開き、一番下の「Menu entries for installing Progressive Web Apps.」にチェックを入れる。

vivaldi://experiments/ の画面

(2) PWA に対応したサイトにアクセス。

(3) タブで右クリックして表示されたメニューから「○○○」をインストール...」を選択。
プルダウンメニュー

Vivaldi 4.2 ではまだ試験的な機能で動作の保証はなさそうなので、あくまで自己責任で。少なくとも、インストールしたアプリ(Macの場合は $HOME/Applications/Chrome Apps.localized/○○○.app)を直接起動すると、ブラウザの1ウィンドウとして開いてしまい、本来は表示されないはずのアドレスバーなどのブラウザのヘッダ部分が表示される不具合があります。まずは一旦ブラウザで対象サイトにアクセスした後、タブで右クリックして表示されたメニューから「○○○で開く」を選択すれば想定通りに動作するようです。
プルダウンメニュー(アプリを起動)

2021年10月7日追記
Vivaldi 4.3 からは直接アプリを起動しても正常に動作するようになりました。
posted by yamaga at 21:17| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年09月02日

「海の向こうの“セキュリティ”」第180回公開

今月分が公開されました。

「サプライチェーン攻撃」に備えるために供給元と顧客が注意すべきこと
ENISAが報告書を公開、攻撃は昨年比4倍増になる見込み
https://internet.watch.impress.co.jp/docs/column/security/1347531.html
posted by yamaga at 06:07| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年08月05日

ENISAによる中小企業向けサイバーセキュリティガイドの参考訳

ENISA(欧州ネットワーク情報セキュリティ機関)が6月末に公開した「Cybersecurity guide for SMEs - 12 steps to securing your business」を翻訳してみました。あくまで参考訳にすぎませんので、正式な場では必ず原文を参照してください。
Cybersecurity guide for SMEs - 12 steps to securing your business
https://www.enisa.europa.eu/publications/cybersecurity-guide-for-smes
なお、このガイドについては、INTERNET Watchで連載中の「海の向こうの“セキュリティ”」でも紹介しています。
海の向こうの“セキュリティ”
中小企業のシステムやビジネスをセキュアにするための12のステップ
「サイバーセキュリティガイド」をENISAが公開
https://internet.watch.impress.co.jp/docs/column/security/1341091.html


中小企業のためのサイバーセキュリティガイド
ビジネスをセキュアにするための12のステップ

STEP1 優れたサイバーセキュリティ文化の構築

管理責任の割り当て

優れたサイバーセキュリティは、あらゆる中小企業の継続的な成功のための重要な要素である。この重要な機能に対する責任は、組織内の者に割り当てられるべきであり、担当者の時間、サイバーセキュリティ・ソフトウェア、サービス、ハードウェアの購入、スタッフのトレーニング、効果的なポリシーの策定など、適切なリソースがサイバーセキュリティに与えられるようにする必要がある。

従業員の同意の獲得

経営陣がサイバーセキュリティに関する効果的なコミュニケーションを行い、経営陣がサイバーセキュリティの取り組みを率直に支持し、従業員に適切なトレーニングを実施し、サイバーセキュリティポリシーに記載された明確で具体的なルールを従業員に提供することで、従業員の同意を得る。

サイバーセキュリティポリシーの発表

会社のICT環境、機器、およびサービスを使用する際に、従業員がどのように行動することが期待されるかについて、明確かつ具体的なルールをサイバーセキュリティポリシーで説明する必要がある。また、これらのポリシーは、従業員がポリシーを遵守しなかった場合に直面し得る結果を強調する必要がある。ポリシーは定期的に見直し、更新する必要がある。

サイバーセキュリティ監査の実施

定期的な監査は、適切な知識、スキル、経験を有する者が実施すべきである。監査人は、外部の契約者または中小企業の内部の者で、日常のIT業務から独立した者でなければならない。

データ保護を忘れずに

EU一般データ保護規則(GDPR: General Data Protection Regulation)に基づき、EU/EEA居住者の個人データを処理または保存する中小企業は、そのデータを保護するために適切なセキュリティ管理が行われていることを確認する必要がある。これには、中小企業に代わって業務を行う第三者が、適切なセキュリティ対策を講じていることも含まれる。

STEP2 適切なトレーニングの提供

すべての従業員がさまざまなサイバーセキュリティの脅威を認識し、対処できるように、定期的にサイバーセキュリティの意識向上のためのトレーニングを実施する。これらのトレーニングは、中小企業向けにカスタマイズされ、実際の状況に焦点を当てるべきである。

企業内でサイバーセキュリティを管理する責任者に、サイバーセキュリティに特化したトレーニングを提供し、職務遂行に必要なスキルとコンピテンシーを確実に身につけさせる。

STEP3 効果的なサードパーティ管理の徹底

すべてのベンダー、特に機密なデータやシステムにアクセスできるベンダーが積極的に管理され、合意されたセキュリティレベルを満たすようにする。ベンダーがこれらのセキュリティ要件をどのように満たすかを規制するために、契約上の合意が必要である。

STEP4 インシデント対応計画の策定

正式なインシデント対応計画を策定する。この計画では、明確なガイドライン、役割と責任が文書化されており、すべてのセキュリティ・インシデントがタイムリーかつ専門的で適切な方法で対応されることを保証する。セキュリティ上の脅威に迅速に対応するために、不審な活動やセキュリティ侵害が発生した場合に監視して警告を発するツールを調査する。

STEP5 システムへのアクセスのセキュア化

パスフレーズの使用を全員に奨励する。パスフレーズとは、一般的な単語をランダムに3つ以上組み合わせたフレーズのことで、覚えやすさとセキュリティのバランスが非常に優れている。一般的なパスワードを使用する場合は以下の点に注意すること。
  • 小文字と大文字、可能であれば数字や特殊文字も使って長くする。
  • 「password」のようなわかりやすいもの、「abc」のような文字や数字の羅列、「123」のような数字は避ける。
  • ネット上で見つけられるような個人情報の使用は避ける。
また、パスフレーズやパスワードのどちらを使う場合でも以下の点に注意すること。
  • 他のところで再利用しない。
  • 同僚と共有しない。
  • 多要素認証を有効にする。
  • 専用のパスワードマネージャーを使用する。

STEP6 デバイスのセキュア化

デスクトップPC、ノートパソコン、タブレット、スマートフォンなど、スタッフが使用するデバイスをセキュアに保つことは、サイバーセキュリティプログラムの重要なステップである。

ソフトウェアにパッチを適用して最新の状態に保つ

パッチを管理するには、集中管理されたプラットフォームを利用するのが理想的である。中小企業には以下のことが強く推奨される。
  • すべてのソフトウェアを定期的に更新する。
  • 可能な限り自動アップデートを有効にする。
  • 手動でのアップデートが必要なソフトウェアやハードウェアを特定する。
  • モバイルデバイスやIoTデバイスを考慮に入れる。

アンチウイルス

集中管理されたアンチウイルスソリューションは、継続的に効果を発揮するために、すべての種類のデバイスに導入し、最新の状態に保つ必要がある。また、海賊版ソフトウェアにはマルウェアが含まれている可能性があるため、インストールしない。

電子メールとウェブの保護ツールの採用

スパムメール、悪意のあるウェブサイトへのリンクを含むメール、ウイルスなどの悪意のある添付ファイルを含むメール、フィッシングメールなどをブロックするソリューションを採用する。

暗号化

データを暗号化して保護する。中小企業は、ノートパソコン、スマートフォン、タブレットなどのモバイル機器に保存されているデータを確実に暗号化する必要がある。ホテルや空港のWiFiネットワークなどの公共ネットワークを介して転送されるデータについては、VPN(Virtual Private Network)を採用するか、SSL/TLSプロトコルを使用したセキュアな接続でウェブサイトにアクセスするなどして、データが暗号化されていることを保証する。自社のウェブサイトに適切な暗号化技術を採用し、インターネット上を流れる顧客データを保護することを保証する。

モバイルデバイス管理の実施

スタッフのリモートワークを促進するために、多くの中小企業ではスタッフが自分のノートパソコン、タブレット、スマートフォンを使用することを許可している。この場合、これらのデバイスに保存されている機密性の高いビジネスデータについて、いくつかのセキュリティ上の懸念が生じる。このリスクを管理する1つの方法として、モバイルデバイス管理(MDM)ソリューションを採用することで、中小企業は以下のことが可能になる。
  • 自社のシステムやサービスへのアクセスを許可するデバイスを管理する。
  • デバイスに最新のアンチウイルス・ソフトウェアがインストールされていることを徹底する。
  • デバイスが暗号化されているかどうかを判断する。
  • デバイスに最新のソフトウェアパッチがインストールされているかどうかを確認する。
  • デバイスがPINおよび/またはパスワードで保護されていることを徹底する。
  • デバイスの所有者がデバイスの紛失や盗難を報告した場合、またはデバイスの所有者が中小企業との雇用関係を終了した場合、デバイスから中小企業のデータを遠隔操作で消去する。

STEP7 ネットワークのセキュア化

ファイアウォールの採用

ファイアウォールは、ネットワークに出入りするトラフィックを管理するもので、中小企業のシステムを保護するための重要なツールである。ファイアウォールは、すべての重要なシステムを保護するために導入する必要がある。特に、中小企業のネットワークをインターネットから保護するためにファイアウォールを採用する必要がある。

リモートアクセスソリューションの見直し

中小企業は、あらゆるリモートアクセスツールを定期的に見直し、セキュアであることを保証する必要がある。その際には特に以下の点に注意する。
  • すべてのリモートアクセスソフトウェアにパッチが適用され、最新の状態になっていることを徹底する。
  • 不審な地理的位置または特定のIPアドレスからのリモートアクセスを制限する。
  • スタッフのリモートアクセスを業務に必要なシステムやコンピュータに限定する。
  • リモートアクセスに強力なパスワードを設定し、可能であれば多要素認証を有効にする。
  • 攻撃の疑いや通常とは異なる不審な活動を警告するために監視とアラートが有効になっていることを徹底する。

STEP8 物理的セキュリティの改善

重要な情報が存在するところでは、適切な物理的管理を行う必要がある。例えば、会社のノートパソコンやスマートフォンを車の後部座席に放置してはいけない。また、ユーザーがコンピュータから離れる際には常にロックをかける必要がある。もしくは、業務目的で使用するデバイスではオートロック機能を有効にする。また、機密性の高い印刷文書も放置せず、使用しない時はセキュアに保管する。

STEP9 バックアップのセキュア化

重要なフォーメーション(組織編成)の復旧を可能にするためには、ランサムウェア攻撃などの大惨事から復旧するための有効な手段であるバックアップを維持する必要がある。以下のバックアップルールを適用すること。
  • バックアップは定期的に行い、可能な限り自動化する。
  • バックアップは中小企業の本番環境とは別に保持する。
  • バックアップは、特に拠点間で移動する場合は、暗号化する。
  • バックアップからデータを定期的にリストア(復元)できるかテストする。理想的には、最初から最後までのフルリストアのテストを定期的に行うべきである。

STEP10 クラウドとの連携

クラウドベースのソリューションには多くの利点がある一方で、いくつかの固有のリスクがあり、それらを中小企業はクラウド事業者と連携する前に検討する必要がある。ENISAは中小企業がクラウドに移行する際に参考にすべき「中小企業のためのクラウドセキュリティガイド」を発行している。
ENISA (2015-04-10)
Cloud Security Guide for SMEs
https://www.enisa.europa.eu/publications/cloud-security-guide-for-smes
クラウド事業者を選定する際には、中小企業は、データ、特に個人データをEU/EEA域外に保存しても、いかなる法律や規制にも違反しないことを保証する必要がある。例えば、EUのGDPRでは、EU/EEA域内の居住者の個人データは、よほど特殊な事情がない限り、EU/EEA域外に保存・送信しないことが定められている。

STEP11 オンラインサイトのセキュア化

中小企業は、自社のオンラインウェブサイトをセキュアな方法で設定・維持し、且つ個人データやクレジットカード情報などの財務情報を適切に保護することが極めて重要である。そのためには、ウェブサイトに対して定期的にセキュリティテストを行って潜在的なセキュリティ上の弱点を洗い出すとともにサイトが適切に維持・更新されているかを定期的に確認する必要がある。

STEP12 情報の収集と共有

サイバー犯罪との闘いにおける効果的なツールは情報の共有である。中小企業が直面するリスクをよりよく理解するためにはサイバー犯罪に関する情報を共有することが重要である。サイバーセキュリティ上の課題とその克服方法を同業他社から聞いた企業は、業界レポートやサイバーセキュリティ調査で同様の内容を聞いた場合よりも、自社のシステムをセキュアにするための措置を取る可能性が高くなる。
posted by yamaga at 06:09| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

「海の向こうの“セキュリティ”」第179回公開

今月分が公開されました。

中小企業のシステムやビジネスをセキュアにするための12のステップ
「サイバーセキュリティガイド」をENISAが公開
https://internet.watch.impress.co.jp/docs/column/security/1341091.html
posted by yamaga at 06:07| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年07月29日

MIT Kerberos5 1.19.2 で LibreSSL 3.3.3 を使うためのパッチ

MIT Kerberos5 1.19.2LibreSSL 3.3.3 を使うためには以下のパッチをあてれば良さそう。
diff -ru ../krb5-1.19.2.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
--- ../krb5-1.19.2.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-07-23 00:50:07.000000000 +0900
+++ ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-07-29 07:50:37.984361221 +0900
@@ -185,7 +185,7 @@
(*_x509_pp) = PKCS7_cert_from_signer_info(_p7,_si)
#endif

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER)

/* 1.1 standardizes constructor and destructor names, renaming
* EVP_MD_CTX_{create,destroy} and deprecating ASN1_STRING_data. */
posted by yamaga at 10:06| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年07月01日

「海の向こうの“セキュリティ”」第178回公開

今月分が公開されました。

「PSIRT」の認知度の低さが浮き彫りに
EUにおけるPSIRTの実態に関する調査結果をENISAが公開
https://internet.watch.impress.co.jp/docs/column/security/1335152.html
posted by yamaga at 06:08| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年06月03日

「海の向こうの“セキュリティ”」第177回公開

今月分が公開されました。

クラウドで発生したインシデントに対応するためには
クラウドセキュリティの非営利団体CSAがガイドを公開
https://internet.watch.impress.co.jp/docs/column/security/1328159.html
posted by yamaga at 06:11| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年05月13日

MIT Kerberos5 1.19.1 で LibreSSL 3.3.3 を使うためのパッチ

MIT Kerberos5 1.19.1LibreSSL 3.3.3 を使うためには以下のパッチをあてれば良さそう。
diff -ru ../krb5-1.19.1.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
--- ../krb5-1.19.1.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-02-19 01:35:16.000000000 +0900
+++ ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-05-13 11:32:57.486561687 +0900
@@ -185,7 +185,7 @@
(*_x509_pp) = PKCS7_cert_from_signer_info(_p7,_si)
#endif

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER)

/* 1.1 standardizes constructor and destructor names, renaming
* EVP_MD_CTX_{create,destroy} and deprecating ASN1_STRING_data. */
posted by yamaga at 14:00| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年05月06日

「海の向こうの“セキュリティ”」第176回公開

今月分が公開されました。

アプリに含まれるライブラリが原因で“脆弱性あり”に判定される「偽陽性」問題
米セキュリティ企業Contrast Securityが報告書を公開
https://internet.watch.impress.co.jp/docs/column/security/1321965.html
posted by yamaga at 06:09| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年04月08日

「海の向こうの“セキュリティ”」第175回公開

今月分が公開されました。

CSIRTが倫理的に行動するために必要なこと
CSIRTの倫理ガイドライン ほか
https://internet.watch.impress.co.jp/docs/column/security/1316623.html
posted by yamaga at 06:16| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年03月04日

「海の向こうの“セキュリティ”」第174回公開

今月分が公開されました。

産業用制御システムの脆弱性調査市場が成長、研究者たちの関心集まる
イスラエルのセキュリティ企業が報告書を公開
https://internet.watch.impress.co.jp/docs/column/security/1309585.html
posted by yamaga at 06:09| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年03月01日

MIT Kerberos5 1.19.1 で LibreSSL 3.2.4 を使うためのパッチ

MIT Kerberos5 1.19.1LibreSSL 3.2.4 を使うためには以下のパッチをあてれば良さそう。
diff -ru ../krb5-1.19.1.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
--- ../krb5-1.19.1.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-02-19 01:35:16.000000000 +0900
+++ ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-02-25 12:14:50.663519650 +0900
@@ -185,7 +185,7 @@
(*_x509_pp) = PKCS7_cert_from_signer_info(_p7,_si)
#endif

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER)

/* 1.1 standardizes constructor and destructor names, renaming
* EVP_MD_CTX_{create,destroy} and deprecating ASN1_STRING_data. */
posted by yamaga at 11:52| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2021年02月06日

MIT Kerberos5 1.19 で LibreSSL 3.2.3 を使うためのパッチ

MIT Kerberos5 1.19LibreSSL 3.2.3 を使うためには以下のパッチをあてれば良さそう。
diff -ru ../krb5-1.19.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
--- ../krb5-1.19.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-02-02 04:49:04.000000000 +0900
+++ ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 2021-02-06 11:24:59.433039366 +0900
@@ -185,7 +185,7 @@
(*_x509_pp) = PKCS7_cert_from_signer_info(_p7,_si)
#endif

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER)

/* 1.1 standardizes constructor and destructor names, renaming
* EVP_MD_CTX_{create,destroy} and deprecating ASN1_STRING_data. */
posted by yamaga at 18:50| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする