私たちの周りには、スマートスピーカー、監視カメラ、スマート家電など、インターネットに接続された便利な「モノ」、いわゆるIoT (Internet of Things) デバイスが溢れています。しかし、その便利さの裏側には、セキュリティのリスクが潜んでいることをご存知でしょうか？ 💻
IoTデバイスは、その特性上、サイバー攻撃の標的となりやすい一面を持っています。性能が限定されていたり、一度設置されると管理されにくかったり、長期間利用されたりするためです。実際に、2021年にはIoTデバイスへの攻撃が前年比で倍増し、1.5兆件以上も発生したという報告もあります。😱
そこで重要になるのが、IoTデバイスのセキュリティ対策です。その指針として世界的に認知されているのが、OWASP (Open Web Application Security Project) が公開している「OWASP IoT Top 10」です。OWASPは、Webアプリケーションのセキュリティ向上を目的としたオープンソース・コミュニティであり、その知見はIoTセキュリティにも活かされています。
OWASP IoT Top 10は、IoTデバイスにおける特に重大な10個のセキュリティリスクをまとめたものです。開発者、製造業者、そして私たち利用者が、IoTシステムをより安全に利用するための重要なガイドラインとなります。最新版は2018年に公開されたものですが、現在でも多くのIoTデバイスに共通する脆弱性を示しています。
このブログでは、OWASP IoT Top 10 2018の各項目を、具体的な事例や対策方法を交えながら、分かりやすく解説していきます。あなたの身の回りにあるIoTデバイスの安全性を確認し、安心して利用するためのヒントを見つけてください。🛡️
OWASP IoT Top 10 – 2018年版 リスト
以下がOWASP IoT Top 10 2018で指摘されている10のリスクです。
| リスクID | リスク名（英語） | リスク名（日本語） | 概要 |
|---|---|---|---|
| I1 | Weak, Guessable, or Hardcoded Passwords | 脆弱・推測可能・ハードコードされたパスワード | 推測しやすい、初期設定のまま、あるいは変更不可能なパスワードの問題。 |
| I2 | Insecure Network Services | 安全でないネットワークサービス | 不要または安全でないネットワークサービスがデバイス上で動作している問題。 |
| I3 | Insecure Ecosystem Interfaces | 安全でないエコシステムインターフェース | Web、API、クラウド、モバイル等の外部インターフェースの脆弱性。 |
| I4 | Lack of Secure Update Mechanism | 安全な更新メカニズムの欠如 | ファームウェア等を安全に更新する仕組みがない問題。 |
| I5 | Use of Insecure or Outdated Components | 安全でない、または古いコンポーネントの使用 | 脆弱性のある古いソフトウェア部品やライブラリを使用している問題。 |
| I6 | Insufficient Privacy Protection | 不十分なプライバシー保護 | 個人情報や機密データの収集・保存・利用が不適切な問題。 |
| I7 | Insecure Data Transfer and Storage | 安全でないデータ転送と保存 | データの送受信や保存時に暗号化やアクセス制御が不十分な問題。 |
| I8 | Lack of Device Management | デバイス管理の欠如 | 導入後のデバイス管理（更新、監視、廃棄等）が不十分な問題。 |
| I9 | Insecure Default Settings | 安全でないデフォルト設定 | 初期設定が安全でなく、変更も困難な場合がある問題。 |
| I10 | Lack of Physical Hardening | 物理的な保護の欠如 | デバイス自体への物理的なアクセスや改ざん対策が不十分な問題。 |
それでは、各項目について詳しく見ていきましょう。👇
I1: 脆弱・推測可能・ハードコードされたパスワード (Weak, Guessable, or Hardcoded Passwords)
どんなリスク？
IoTデバイスへの攻撃で最も古典的かつ効果的なのが、パスワードに関する問題です。多くのデバイスが出荷時に「admin/admin」や「password」のような単純で推測しやすいパスワードを設定しています。さらに悪いことに、これらのパスワードがソースコード内に直接書き込まれていて（ハードコード）、ユーザーが変更できないケースもあります。
攻撃者は、これらの有名な初期パスワードのリストを使って、インターネット上で無防備なデバイスを探し出し、簡単に侵入できてしまいます。また、パスワードが変更できたとしても、ユーザーが単純なもの（例: 123456）を設定してしまうことも問題です。ブルートフォース攻撃（総当たり攻撃）に対するアカウントロック機能などが備わっていない場合、時間をかければ破られてしまう可能性があります。
事例：Mirai ボットネット (2016年)
マルウェア「Mirai」は、まさにこの脆弱性を悪用しました。工場出荷時のデフォルトパスワードや弱いパスワードが設定されたルーターやWebカメラなどのIoTデバイスをスキャンし、感染させて巨大なボットネットを形成。このボットネットを利用して、大規模なDDoS攻撃（分散型サービス妨害攻撃）を引き起こし、大手DNSサービスプロバイダーやセキュリティ情報サイトをダウンさせました。
対策は？
- 強力な初期パスワード: 製造者は、推測困難でユニークな初期パスワードを設定する。
- パスワード変更の強制: ユーザーが初回設定時に必ずパスワードを変更するように要求する。
- パスワード強度要件: 文字数、文字種（大文字、小文字、数字、記号）などの要件を設け、弱いパスワードを設定できないようにする。
- ハードコードしない: パスワードをファームウェアなどにハードコードしない。
- 総当たり攻撃対策: 一定回数ログインに失敗したらアカウントをロックする、CAPTCHAを導入するなどの対策を行う。
- 多要素認証 (MFA): 可能であれば、パスワードに加えて別の認証要素（SMSコード、認証アプリなど）を組み合わせる。
I2: 安全でないネットワークサービス (Insecure Network Services)
どんなリスク？
IoTデバイスは、設定や管理、他のデバイスとの連携のために、様々なネットワークサービス（例: Webサーバー、Telnet、SSH、FTP、UPnPなど）を動作させています。しかし、これらのサービスが必要ないのに有効になっていたり、古いバージョンのまま放置されていたり、設定が不適切だったりすると、攻撃の侵入口となります。
特に、これらのサービスがインターネットに直接公開されている場合、非常に危険です。攻撃者は、脆弱なサービスを発見し、そこからデバイスに不正アクセスしたり、設定を変更したり、機密情報を盗んだり、さらにはデバイスを乗っ取って他の攻撃の踏み台にしたりする可能性があります。
事例：
特定のメーカーのネットワークカメラに搭載されていた古いWebサーバーソフトウェアに脆弱性が見つかり、認証なしで映像を閲覧されたり、設定を変更されたりするインシデントが発生しました。また、不要なTelnetサービスが有効になっていたルーターが、前述のMiraiなどのマルウェアに感染するケースも多く報告されています。
対策は？
- 不要なサービスの無効化: デバイスの機能に必須でないネットワークサービスやポートはデフォルトで無効にする。
- セキュアなプロトコルの使用: TelnetやFTPのような平文通信ではなく、SSHやSFTP/FTPSのような暗号化されたプロトコルを使用する。
- アクセス制御: ファイアウォール機能で、必要な通信相手以外からのアクセスを拒否する。
- 最新バージョンの維持: ネットワークサービスを提供するソフトウェアを常に最新の状態に保ち、既知の脆弱性を修正する。
- ネットワークセグメンテーション: IoTデバイスを他の重要なネットワーク（社内LANなど）から分離する。
- 侵入検知・防御システム (IDS/IPS): 不審な通信を検知し、ブロックする仕組みを導入する。
I3: 安全でないエコシステムインターフェース (Insecure Ecosystem Interfaces)
どんなリスク？
IoTデバイスは単体で動作することは少なく、スマートフォンアプリ、Web管理画面、クラウドサービス、他のIoTデバイスなど、様々な外部コンポーネントと連携して「エコシステム」を形成しています。このエコシステム間の連携に使われるインターフェース（APIなど）のセキュリティが不十分だと、そこが攻撃の起点となります。
よくある問題としては、以下のようなものが挙げられます。
- 認証・認可の欠如/不備: APIへのアクセスに適切な認証（誰がアクセスしているか）や認可（何をする権限があるか）がない、または不十分。
- 暗号化の欠如/脆弱な暗号化: APIとの通信が暗号化されていない（HTTP）、または古い・弱い暗号方式（古いSSL/TLSバージョンなど）を使用している。
- 不適切な入力検証: APIが受け取るデータ（ユーザーからの入力など）を適切に検証せず、不正なコード（SQLインジェクションなど）を実行してしまう。
事例：
あるスマートホーム製品のクラウドAPIに認証不備があり、他人のアカウントのデバイスを操作できてしまう脆弱性が見つかりました。また、モバイルアプリとデバイス間の通信が暗号化されておらず、中間者攻撃によって認証情報が盗まれるケースもありました。
対策は？
- 適切な認証・認可: APIやインターフェースへのアクセスには、強力な認証（APIキー、OAuthなど）と、最小権限の原則に基づいた認可を実装する。
- 通信の暗号化: すべての通信（デバイス-クラウド間、アプリ-API間など）をTLSなどの強力な暗号化プロトコルで保護する。
- 入力値検証: APIが受け取るすべての入力値を厳格に検証し、不正なデータやコードをフィルタリングする。
- APIセキュリティのベストプラクティス適用: レート制限（過剰なリクエストの制限）、適切なエラーハンドリング、セキュリティヘッダーの実装などを行う。
- 定期的な脆弱性診断: Webインターフェース、API、モバイルアプリなど、エコシステム全体の脆弱性を定期的に診断する。
I4: 安全な更新メカニズムの欠如 (Lack of Secure Update Mechanism)
どんなリスク？
ソフトウェアに脆弱性が見つかった場合、修正パッチや新しいバージョンのファームウェアを配布して更新する必要があります。しかし、IoTデバイスにおいて、この更新プロセス自体が安全でない場合、さらなるリスクを生み出してしまいます。
具体的な問題点としては、以下のようなものが挙げられます。
- 更新ファイルの検証不備: デバイスが、ダウンロードした更新ファイルが正規のものであるか（改ざんされていないか、信頼できる発行元か）を検証しない。
- 更新経路の非暗号化: 更新ファイルが暗号化されずに配布されるため、通信経路上で盗聴されたり、改ざんされたりする可能性がある。
- ロールバック攻撃への耐性欠如: 古いバージョンの脆弱なファームウェアへのダウングレード（ロールバック）を防ぐ仕組みがない。
- 更新通知の不備: ユーザーに更新があることや、更新によるセキュリティ変更点が適切に通知されない。
事例：
一部のルーターで、ファームウェア更新ファイルがHTTP経由で配布され、署名検証も行われていなかったため、中間者攻撃によって悪意のあるファームウェアを送り込まれる可能性が指摘されました。
対策は？
- ファームウェア署名検証: 更新ファイルにはデジタル署名を付与し、デバイス側で必ず署名を検証してから適用する。
- 安全な更新チャネル: 更新ファイルはHTTPSなどの暗号化された経路で配布する。
- アンチロールバック機構: 一度アップデートしたら、脆弱性のある古いバージョンに戻せないようにする。
- 更新通知と透明性: ユーザーに更新の必要性を明確に通知し、更新内容（特にセキュリティ関連の修正）を説明する。
- 自動更新機能（オプション）: ユーザーの手間を省き、常に最新の状態を保つために、安全な自動更新機能を提供する（ただし、ユーザーが無効化できる選択肢も用意する）。
I5: 安全でない、または古いコンポーネントの使用 (Use of Insecure or Outdated Components)
どんなリスク？
IoTデバイスを含む多くのソフトウェア製品は、ゼロからすべて開発されるわけではなく、オープンソースソフトウェア（OSS）のライブラリやフレームワーク、サードパーティ製のソフトウェアコンポーネントなどを組み合わせて作られています。これらの利用するコンポーネント自体に既知の脆弱性が存在したり、サポートが終了して古くなっていたりすると、デバイス全体のセキュリティレベルが低下します。
例えば、古いバージョンのOS、脆弱性が見つかっている通信ライブラリ、サポート切れのWebサーバーソフトウェアなどが使われているケースです。攻撃者は、これらの公開されている脆弱性を悪用してデバイスに侵入することができます。サプライチェーン（部品供給網）の途中で不正なコンポーネントが混入するリスクもあります。
事例：Heartbleed (2014年) や Log4Shell (2021年)
これらは特定のライブラリ（OpenSSL、Log4j）で見つかった重大な脆弱性ですが、これらのライブラリは非常に多くのWebサーバーやアプリケーション、そしてIoTデバイスでも利用されていました。そのため、影響範囲が非常に広く、多くのシステムが危険にさらされました。IoTデバイスの場合、修正パッチの適用が難しいケースもあり、長期間脆弱なまま放置されることもありました。
対策は？
- ソフトウェア部品表 (SBOM: Software Bill of Materials) の管理: デバイスに使用しているすべてのソフトウェアコンポーネント（バージョン情報含む）をリスト化し、管理する。
- 脆弱性情報の監視: 使用しているコンポーネントに関する脆弱性情報（CVEなど）を継続的に監視する。
- コンポーネントの更新: 脆弱性が見つかったコンポーネントは、速やかに安全なバージョンに更新するプロセスを確立する。
- サポート期間の確認: 利用するコンポーネントのサポート期間を確認し、サポート切れのものは使用しない、または代替策を検討する。
- 信頼できるソースからの入手: コンポーネントは公式サイトなど、信頼できるソースから入手する。
- サプライチェーンセキュリティ: サードパーティから提供されるコンポーネントのセキュリティも確認する。
I6: 不十分なプライバシー保護 (Insufficient Privacy Protection)
どんなリスク？
IoTデバイスは、ユーザーの行動、位置情報、音声、映像、健康情報など、非常にプライベートな情報を収集することがあります。これらの個人情報や機密データが、ユーザーの同意なく収集されたり、必要以上に収集されたり、不適切に利用されたり、安全でない方法で保存・転送されたりすると、プライバシー侵害につながります。
例えば、スマートスピーカーが常に会話を録音してクラウドに送信している、フィットネストラッカーの位置情報がユーザーの意図しない第三者に共有されている、監視カメラの映像が暗号化されずに保存されている、といったケースが考えられます。これらの情報は、マーケティング目的で悪用されたり、攻撃者に盗まれて悪用されたりする可能性があります。GDPR（EU一般データ保護規則）などの法規制への準拠も重要です。
事例：
過去に、一部のスマートトイが子供の音声を収集し、安全でないサーバーに保存していたことが問題となりました。また、ユーザーの位置情報を追跡するアプリ連携のIoTデバイスが、そのデータを第三者に販売していたケースも報告されています。
対策は？
- プライバシーポリシーの明確化: どのようなデータを収集し、どのように利用・保存・共有するのかを明確に記載し、ユーザーに分かりやすく提示する。
- 収集するデータの最小化: サービスの提供に必要な最低限のデータのみを収集する（データ最小化の原則）。
- ユーザーの同意取得: 個人情報を収集・利用する際には、必ずユーザーから明確な同意を得る。
- データの匿名化・仮名化: 可能であれば、個人を特定できないようにデータを匿名化または仮名化して処理する。
- ユーザーによるデータ制御: ユーザーが自身のデータにアクセスし、修正・削除できるようにする。データ収集の設定（オン/オフ）をユーザーが制御できるようにする。
- 安全なデータ管理: 収集したデータは、次のI7で述べるように、安全に転送・保存する。
I7: 安全でないデータ転送と保存 (Insecure Data Transfer and Storage)
どんなリスク？
IoTデバイスや関連するエコシステム（クラウド、アプリ）で扱われるデータ（個人情報、認証情報、設定情報など）が、転送中や保存中に適切に保護されていない場合、盗聴、改ざん、漏洩のリスクがあります。
具体的な問題点としては、
- 転送中の非暗号化: デバイスとクラウド間、アプリとサーバー間などの通信がHTTPやFTPなど暗号化されていないプロトコルで行われている。
- 保存時の非暗号化: 機密データがデバイスのストレージやクラウドデータベースに平文のまま保存されている。
- 不適切なアクセス制御: 保存されているデータへのアクセス権限が適切に設定されておらず、権限のないユーザーやプロセスがアクセスできてしまう。
- 弱い暗号化方式の使用: 古い、または脆弱な暗号アルゴリズムや短い鍵長が使用されている。
- 鍵管理の不備: 暗号化に使用する鍵がハードコードされていたり、安全でない方法で管理されていたりする。
事例：
あるフィットネスアプリでは、ユーザーの認証情報や健康データが暗号化されずにサーバーに送信されており、中間者攻撃によって容易に盗み見ることが可能でした。また、データベースの設定ミスにより、クラウド上に保存されていた大量のユーザーデータが誰でもアクセスできる状態になっていた事例もあります。
対策は？
- 転送データの暗号化: すべての通信経路でTLSなどの強力な暗号化プロトコルを使用する。
- 保存データの暗号化: デバイス上およびサーバー上で保存される機密データは、強力な暗号化アルゴリズム（AESなど）で暗号化する。
- 厳格なアクセス制御: データへのアクセスは、役割ベースのアクセス制御（RBAC）などを用いて、必要最小限の権限を持つユーザー/プロセスに限定する。
- 強力な暗号化方式と鍵管理: 推奨される最新の暗号アルゴリズムと適切な鍵長を使用し、暗号鍵は安全に生成・保管・ローテーションする。
- データ完全性の検証: データが転送中や保存中に改ざんされていないことを確認するために、ハッシュ値やメッセージ認証コード（MAC）などを使用する。
- 定期的なセキュリティ評価: データ転送・保存に関するセキュリティ対策が適切に実装されているか定期的に評価する。
I8: デバイス管理の欠如 (Lack of Device Management)
どんなリスク？
IoTデバイスは一度導入されると、長期間にわたって運用されることが多く、その間の管理体制が不十分だとセキュリティリスクが高まります。特に、多数のデバイスを運用する場合、個々のデバイスの状態を把握し、適切に管理することが困難になりがちです。
具体的な問題点としては、以下のようなものが挙げられます。
- 資産管理の不備: ネットワーク上にどのようなデバイスが、いくつ存在し、どのバージョンで動作しているのかを把握できていない。
- 更新管理の不備: ファームウェアやソフトウェアの更新が適切に行われず、脆弱性が放置されている。
- 監視体制の欠如: デバイスの稼働状況やセキュリティインシデントの兆候を監視する仕組みがない。
- インシデント対応計画の欠如: セキュリティ侵害が発生した場合の対応計画や手順が定められていない。
- 安全な廃棄プロセスの欠如: デバイスを廃棄する際に、内部に残った機密データが適切に消去されていない。
対策は？
- 集中管理プラットフォームの導入: 多数のデバイスを効率的に管理・監視するためのプラットフォームを導入する。
- 資産インベントリの維持: ネットワーク上のすべてのIoTデバイスを識別し、状態（ファームウェアバージョン、設定など）を記録・管理する。
- 自動化された更新・パッチ管理: 更新プログラムの適用を自動化または半自動化し、迅速かつ確実に適用できる体制を整える。
- リアルタイム監視とアラート: デバイスのログや通信を監視し、異常な動作やセキュリティインシデントの兆候を検知したらアラートを発する仕組みを構築する。
- インシデント対応計画の策定: インシデント発生時の連絡体制、封じ込め、復旧、原因調査、再発防止策などの手順を明確にする。
- 安全なライフサイクル管理: デバイスの導入から廃棄までの全段階でセキュリティを考慮し、特に廃棄時にはデータを確実に消去する。
I9: 安全でないデフォルト設定 (Insecure Default Settings)
どんなリスク？
多くのIoTデバイスは、ユーザーがすぐに使えるように、予め設定された「デフォルト設定（初期設定）」の状態で出荷されます。しかし、このデフォルト設定がセキュリティ的に甘い場合、大きなリスクとなります。これはI1（弱いパスワード）と関連が深いですが、パスワード以外にも様々な設定項目が該当します。
例えば、以下のようなデフォルト設定が問題となることがあります。
- 推測しやすいデフォルトパスワード: (I1で詳述)
- 不要なサービスの有効化: (I2で詳述) 本来必要ない管理用ポート（Telnetなど）がデフォルトで開いている。
- 暗号化されていない通信: デフォルトでHTTP通信が有効になっている。
- 過剰な権限: デフォルトのユーザーアカウントに管理者権限が付与されている。
- プライバシーに関わる設定: データ共有やログ収集がデフォルトで有効になっている。
事例：
多くの家庭用ルーターが、初期設定で管理画面へのアクセスパスワードが簡単であったり、UPnP（Universal Plug and Play）機能がデフォルトで有効になっており、これがマルウェア感染や不正アクセスの原因となるケースがありました。
対策は？
- セキュア・バイ・デフォルト: 出荷時のデフォルト設定を、可能な限り安全な状態にする（例: 強力なパスワード、不要なサービスの無効化、最小権限）。
- 初期設定時の変更強制: デフォルトパスワードなど、重要なセキュリティ設定は初回起動時にユーザーに変更を強制する。
- 設定変更機能の提供: ユーザーがセキュリティ設定を容易に変更できるように、分かりやすいインターフェースを提供する。
- 設定に関するガイドライン提供: 安全な設定方法について、ユーザー向けのガイドラインやドキュメントを提供する。
- 設定の定期的な見直し推奨: ユーザーに定期的に設定内容を確認・見直すよう促す。
I10: 物理的な保護の欠如 (Lack of Physical Hardening)
どんなリスク？
これまでのリスクは主にネットワーク経由での攻撃を想定していましたが、IoTデバイスは物理的にアクセス可能な場所に設置されることも多いため、デバイス自体への物理的な攻撃（改ざん、盗難、分解など）のリスクも考慮する必要があります。
具体的な問題点としては、以下のようなものが挙げられます。
- デバッグポートの露出: JTAGやUARTなどのデバッグ用インターフェースが保護されずに露出しており、接続されるとメモリ内容を読み取られたり、ファームウェアを書き換えられたりする。
- ストレージの非暗号化: デバイス内のストレージ（SDカード、フラッシュメモリなど）が暗号化されておらず、取り外して読み出すことで機密情報（認証情報、暗号鍵など）が漏洩する。
- 耐タンパー性の欠如: デバイスの筐体が簡単に開けられたり、内部の部品にアクセスできたりする。分解や改ざんを検知する仕組みがない。
- 容易な盗難・持ち去り: デバイス自体が簡単に盗難・持ち去りされ、内部情報を解析される。
事例：
販売時点情報管理（POS）端末からクレジットカード情報を盗み出すスキミング装置の取り付けや、ATMから不正に現金を引き出す攻撃など、物理的なアクセスを伴う攻撃は後を絶ちません。IoTデバイスにおいても、デバッグポートからファームウェアを吸い出してリバースエンジニアリングされたり、機密情報が抜き取られたりする事例が報告されています。
対策は？
- デバッグポートの無効化/保護: 製品出荷時にはデバッグポートを無効化するか、物理的にアクセスできないように保護する。
- ストレージの暗号化: デバイス内のストレージに保存される機密データは暗号化する。特に取り外し可能なメディア（SDカードなど）には機密情報を保存しない。
- 耐タンパー性の向上: 筐体を開封しにくくする、開封や改ざんを検知してデータを消去するなどの耐タンパー機構を導入する。
- セキュアブート: 起動時にファームウェアの署名を検証し、改ざんされたソフトウェアが実行されるのを防ぐ。
- 物理的な設置場所の考慮: デバイスを設置する際には、不正な物理アクセスが困難な場所を選ぶ。
- 重要情報の保護: 暗号鍵などの特に重要な情報は、セキュアエレメント（耐タンパー性のある専用チップ）などに格納する。
まとめ：IoTセキュリティは「みんな」で守るもの 💪
OWASP IoT Top 10 2018で指摘されている10のリスクを見てきました。弱いパスワードから物理的な保護の欠如まで、IoTデバイスには様々なセキュリティ上の課題があることがお分かりいただけたかと思います。
これらのリスクは、決して他人事ではありません。攻撃者は常に脆弱なデバイスを探しており、ひとたび侵害されれば、個人情報の漏洩、金銭的な被害、さらには社会インフラへの影響といった深刻な事態につながる可能性があります。📈
IoTデバイスのセキュリティを確保するためには、「開発者・製造者」、「サービス提供者」、そして「利用者」のそれぞれが責任を果たす必要があります。
- 開発者・製造者: 設計段階からセキュリティを考慮し（セキュア・バイ・デザイン）、OWASP IoT Top 10のようなガイドラインに基づいた安全な製品を作る。
- サービス提供者: 安全な運用体制を構築し、脆弱性への対応やアップデートを継続的に行う。
- 利用者: デフォルトパスワードを変更する、ソフトウェアを最新に保つ、不審な点があれば利用を停止するなど、基本的な対策を実践する。
OWASP IoT Top 10は、これらの対策を進める上での重要な道しるべとなります。このリストを参考に、身の回りのIoTデバイスや関連サービスのセキュリティについて、改めて考えてみましょう。安全で便利なIoTの世界を実現するために、私たち一人ひとりがセキュリティ意識を高めていくことが大切です。🌍✨
コメント