10のScore Factorsで読み解く仕組み

SecurityScorecardのスコアはどう決まる?

SecurityScorecardは、企業のセキュリティ状態を「A〜F」の評価と「0〜100」の点数で表すサービスです(セキュリティレーティング)。取引先のリスク管理(サプライチェーンリスク)でも使われています。

この記事では、評価の中身を10のカテゴリに分けて示すScore Factors(スコア要因)を入り口に、何を見ているのか、どうやって情報を集めているのか、どう点数を決めているのかを整理します。

ポートフォリオの画面:取引先などのスコアを一覧で監視できる(社名とドメインは伏せています)
ポートフォリオの画面:取引先などのスコアを一覧で監視できる(社名とドメインは伏せています)
前提

外から見える情報だけで評価する

SecurityScorecardは、企業の社内ネットワークに入って調べるわけではありません。インターネット側から誰でも見られる情報(公開IPアドレス、ドメイン、DNS、Webサイト、証明書など)と、外部の脅威情報(マルウェアの通信、漏えいデータ、ハッカーの掲示板など)をもとに評価します。

  • 評価される企業の側では、エージェントの導入や設定は不要です。
  • スキャンは「非侵入型」と説明されています。公開されているシステムと通常の範囲でやり取りするだけで、攻撃コードの実行や、脆弱性を実際に突く攻撃(エクスプロイト)は行いません。
  • そのため、社内のPCやファイアウォールの内側の設定は、直接は評価の対象になりません。
10個のScore Factors

何に着目しているか

#Factor見ているもの具体的なチェックの例
1Network Security不正アクセスを防ぐ設定やポリシーが守られているか危険なポートや不要なポートが公開されていないか(RDP、データベース、Telnetなど)、内部ネットワークへの入口になりうる公開サービスがないか
2DNS HealthDNSの設定の安全性と、過去のDNSの記録DNSサーバーの設定ミス、オープンリゾルバ(誰からの問い合わせにも答えてしまい、DDoS攻撃の踏み台になるDNSサーバー)、メールのなりすまし対策(送信元を検証するSPF / DKIM / DMARCなど)、過去のDNS記録に残る悪性のイベント
3Patching Cadenceセキュリティ更新をどれだけ早く当てているか公開サービスのソフトウェアのバージョン、既知の脆弱性(CVE:Common Vulnerabilities and Exposures。脆弱性ごとに振られる共通の識別番号)が残っていないか、同業他社と比べた対応の速さ
4Endpoint Security社員の端末の入口が守られているか古いOS、古いブラウザやプラグインからの通信が観測されていないか
5IP Reputation自社のネットワークで不審な動きがないかマルウェア感染(攻撃者の指令サーバー=C2サーバーへの通信を、シンクホールで捉えて検知)、感染の件数と期間、スパムの送信
6Application SecurityWebアプリによくある脆弱性脆弱なWebアプリや古いバージョン、改ざんの痕跡、CVEやエクスプロイトのデータベースから見た攻撃されやすさ
7Cubit Score一般的なセキュリティのベストプラクティスランサムウェアに狙われやすいリモートアクセスの公開、公開されたサブドメイン、悪用されやすい設定ミス、脅威情報データベースへの掲載
8Hacker Chatterハッカーの間で話題になっていないか地下フォーラム、IRC(チャット)、SNSなどでの社名やサイト名の言及
9Information Leak機密情報が漏れていないか大規模な流出データやハッカー同士の取引に含まれる認証情報、漏えいした社内情報
10Social Engineeringフィッシングなどの「人をだます攻撃」への備えSNSや過去の流出データから見た、フィッシングや標的型攻撃の受けやすさ

ざっくり分けると、次の3種類になります。

  • 設定・構成の問題

    Network Security、DNS Health、Application Security、Cubit Score

  • 運用の問題

    Patching Cadence、Endpoint Security

  • すでに起きていること・狙われている兆し

    IP Reputation、Hacker Chatter、Information Leak、Social Engineering

どういう仕組みで監視しているか

情報の集め方
手法内容
インターネット全体のスキャンIPv4の全アドレス空間を10日ごと、1,400以上のポートでスキャンします。クラウドの資産は1日に複数回スキャンします。
パッシブセンサー世界中に置いた数百のセンサー(ハニーポット、DNSシンクホール)で、マルウェアの感染端末から外への通信を捉えます。
その他の調査DNSレコードの確認、SSL証明書の確認、HTTPヘッダーの取得、Google / GitHubでの検索(Dorking:検索演算子を使い、うっかり公開された設定ファイルや認証情報を探す手法)、ハッカーコミュニティの監視
外部の情報脅威情報フィード、漏えいデータなど
DNSシンクホール:マルウェアの「連絡先」を先回りして押さえる

マルウェアに感染したPCは、攻撃者が感染端末に命令を出すための指令サーバーに「感染したので指示をください」と定期的に通信します。

この指令サーバーをC2サーバー(Command and Control。C&Cサーバーとも呼ばれます)といい、攻撃者はここから、情報の盗み出し、ランサムウェアの実行、ほかの端末への感染拡大などを指示します。

このとき接続先は、IPアドレスではなくドメイン名で指定されることが多いです。IPアドレスは止められやすいので、攻撃者はドメイン名が指すIPアドレス(実際の接続先)を切り替えて逃げられるようにしているためです。

ここを逆手に取るのがシンクホールです。

DNSシンクホールの仕組み:研究者がC2サーバーのドメインを押さえ、感染端末の接続先をシンクホールに向ける
DNSシンクホールの仕組み:研究者がC2サーバーのドメインを押さえ、感染端末の接続先をシンクホールに向ける
  1. マルウェアを解析する

    研究者がマルウェアを解析し、接続先として使うドメイン名を突き止めます。ドメイン名を日付などから自動生成する方式(DGA:Domain Generation Algorithm)でも、生成のルールが分かれば、将来使われるドメイン名まで予測できます。

  2. そのドメインを先に押さえる

    未登録や期限切れのドメインを研究者側で登録します。すでに攻撃者が使っているドメインは、レジストラ(ドメイン名の登録を受け付ける事業者)や法執行機関の協力で差し押さえることもあります。ドメインの持ち主になると、そのドメインについての問い合わせにどのDNSサーバー(権威DNS)が答えるかも決められます。

  3. 接続先を自分のサーバーに向ける

    押さえたドメインのDNSが、研究者側のサーバー(シンクホール)を指すように設定します。感染端末が社内のDNSを使っていても、公開DNSを使っていても、問い合わせは最終的にこの権威DNSに届くため、同じ答え(シンクホールのIPアドレス)が返ります。

  4. 感染端末が接続しに来る

    感染したPCは、攻撃者ではなくシンクホールに接続してきます。そこで、接続元のIPアドレス・接続の日時・マルウェアの種類が記録されます。

有名な例が、2017年5月のWannaCryです。解析中の研究者が、マルウェアが問い合わせている未登録のドメインに気づき、感染の状況を観測するために登録しました。すると、世界中の感染端末からの通信が集まりました。さらに、そのドメインは「つながったら動作を止める」という停止スイッチ(キルスイッチ)だったため、結果的に感染の拡大も止まりました。

ハニーポット:誰も使わないはずの「おとり」を置く

ハニーポットは、本物のサービスを装ったおとりのサーバーです。本来の利用者がいないIPアドレスに置くので、そこに来る通信はほぼすべてが不審なもの(ポートスキャン、パスワードの総当たり、ワームの拡散など)です。接続元のIPアドレスは「攻撃をしている」、つまり乗っ取られている可能性が高いと判断できます。

集めた記録を企業に結びつける

どちらの方法でも、分かるのは「接続元のIPアドレス」です。社内のPCは、ルーターのNAT(社内のプライベートIPアドレスをグローバルIPアドレスに変換する機能)を通って会社のグローバルIPアドレスでインターネットに出ていきます。そのため、シンクホールやハニーポットに記録されるのは会社の出口のIPアドレスです。これを次のDigital Footprintと照らし合わせると、「この会社のネットワークのどこかに感染端末がいる」と判定でき、IP Reputationなどに反映されます。

この方法には限界もあります。

  • 社内のどのPCが感染しているかまでは分かりません。社内のファイアウォールやDNSのログで特定する必要があります。
  • シンクホールで捉えられるのは、研究者がドメインを押さえたマルウェアだけです。検出されないからといって、感染がないとは言い切れません。
  • 通信事業者のCGNAT(Carrier-Grade NAT。多数の契約者で1つのグローバルIPアドレスを共有する仕組み)や共用のIPアドレスでは、別の利用者の通信が混ざる可能性があります。
「どの資産がどの会社のものか」を決める

集めた情報を企業ごとに振り分ける仕組みがDigital Footprintです。DNSレコード、SSL証明書、WHOIS / RIRの登録情報(RIRは地域ごとにIPアドレスを割り当てる組織で、日本ならAPNIC / JPNIC)などから、IPアドレスやドメインを企業に結びつけます。

結びつけた資産には有効期限(TTL)があり、根拠となる情報が再び確認されないと自動で外れます。

根拠有効期限
DNSレコード24時間
ポートスキャン24時間
WHOIS / RIRの登録情報2日
SSL証明書45日
第三者の情報45日
企業自身が登録したもの期限なし(申請で削除)

自社のものではない資産が混ざっていると、評価が不当に下がります。Digital Footprintを確認して、自社の資産を登録し、他社の資産は否認しておくことが大切です。

どう判定しているか

用語:Finding と Issue Type
  • Finding(検出結果)

    「どの資産で」「いつ」「どんな問題が」見つかったか、という1件ずつの記録

  • Issue Type(問題の種類)

    「オープンリゾルバ」「古いTLS」など、問題を種類ごとにまとめたもの。現在は200種類以上あります。

それぞれのIssue Typeには、侵害リスクの大きさに応じて次の区分が付いています。

区分意味点数への影響
High侵害との相関が強い大きい
Medium中程度中くらい
Low弱い小さい
Info(参考情報)相関が小さい、または未評価なし
Positive(良い取り組み)良い設定ができているなし

この区分は、過去4年間の約15,000件の侵害事例を分析し、「どの問題を抱えていた企業が実際に侵害されたか」という相関から決められています(Scoring 3.0、2024年4月から)。

Factorごとの内訳(取引先AのNetwork Securityの例):High / Medium / Lowの各区分と、点数に影響しないPositive / Informationalの件数。太字が検出されたIssue Type
Factorごとの内訳(取引先AのNetwork Securityの例):High / Medium / Lowの各区分と、点数に影響しないPositive / Informationalの件数。太字が検出されたIssue Type
点数の計算
  1. 会社の規模の違いをならす

    Issue Typeごとに、1,200万以上の組織のうち、規模の近い組織の平均と比べます。資産が多い大企業は、その分Findingも多くなりがちだからです。

    • 例:オープンリゾルバの問題は、規模の近い組織の12%で見つかり、平均は2件です。自社で3件見つかれば「平均より悪い」と判定されます。
  2. 偏差のような値に変換する

    Findingが0件なら0、規模の近い組織の平均と同じ件数なら1になる値(修正Zスコア。平均からのずれの大きさを表す統計の指標)に変換します。

  3. 重みを掛けて合計する

    Issue Typeごとの重み(High / Medium / Low)を掛けて合計します。

  4. 点数と評価に変換する

    対数のスケールで0〜100点に変換し、A〜Fの評価を付けます。

評価点数
A90〜100
F60以下

(B〜Dの境目は、公式ヘルプには明記されていません。)

F評価の企業は、A評価の企業に比べて侵害を受ける確率が約13.8倍とされています。

Scoring 2.0までは「10個のFactorの点数の加重平均」が総合点でした。現在のScoring 3.0では、総合点は200種類以上のIssue Typeから直接計算されます。Score Factorsは、それを10のカテゴリに分けて見やすくしたものと考えると分かりやすいです。

更新の頻度
  • 点数は毎日更新されます。
  • 計算方法の基準は毎月見直されます。さらに、数か月に一度の大きな「再計算(recalibration)」があり、自社が何もしていなくても点数が変わることがあります(次回は2026年11月24日の予定)。
  • 平均の計算には2か月分のデータを使い、一時的な変動をならしています。
問題が消えるまで
パターン内容
修正済みとして申請する画面からFindingを「修正済み」にすると、その問題だけをすぐ再スキャンします。検出されなければ、すぐに消えます。
自然に消える(decay)一定の期間、スキャンで同じ問題が見つからなければ自動で消えます。
侵害(Breach)の場合点数への影響は徐々に小さくなり、最後に確認されてから約1か月でゼロになります。記録自体は残ります。
資産が自社のものでなくなった場合IPアドレスの割り当て変更などで、資産がDigital Footprintから外れると消えます。
代替の対策がある場合別の方法で対策している(補完的コントロール)と申請して解決することもできます。

なお、スコアカード全体の再スキャンを手動で依頼することはできません。

実例(2026年10月時点)

取引先Aのスコア

当社が支援している取引先Aのスコアカードを紹介します(社名とドメインは伏せています)。総合は43点・F評価で、Patching CadenceとNetwork Securityの2つのFactorで点数が大きく下がっています。

取引先AのScore Factors:High 1件、Medium 4件、Low 11件の問題が点数を押し下げている
取引先AのScore Factors:High 1件、Medium 4件、Low 11件の問題が点数を押し下げている

Factorを開くと、Issue Typeごとの件数がHigh / Medium / Low / Positive / Informationalに分かれて表示されます。「どう判定しているか」で示した図のとおり、Network Securityでは、古いSSL / TLSプロトコルを受け付けている(High、2件)、IMAPサービスが公開されている(Medium)、自己署名証明書を使っている(Low)などが検出されています。

Patching Cadenceでは、公開サービスのソフトウェアに残る既知の脆弱性(CVSS v3.0)が多数検出されています。Findingsは271件ありますが、点数に影響するのはMedium 1件とLow 172件で、残りは参考情報です。

Patching Cadenceの内訳
Patching Cadenceの内訳

Issuesの画面では、問題ごとに点数への影響(Impact)と、次回の再計算後の影響(Recalibrated impact)を確認できます。Threat levelとBreach riskは別の指標で、たとえば「Site does not enforce HTTPS」はThreat levelがHighでも、侵害との相関を表すBreach riskはLowと判定されています。直す順番は、Breach riskとImpactの大きいものから決めるのが効率的です。

Issuesの画面:問題ごとのThreat level、Breach risk、点数への影響
Issuesの画面:問題ごとのThreat level、Breach risk、点数への影響
実例(2026年10月時点)

取引先Bのスコア

もう1社、建設業大手の取引先のスコアカードを紹介します(社名とドメインは伏せています)。総合は70点・C評価で、建設業の平均81点(B)を下回っています。

このスコアカードは67の組織からフォロー(監視)されています。それでも過去1年の推移を見るかぎり、点数は業種平均を下回ったままで、目立った改善は見られません。

取引先Bの概要画面:総合スコアと推移、Breach Susceptibility Indicator、Ransomware Score
取引先Bの概要画面:総合スコアと推移、Breach Susceptibility Indicator、Ransomware Score
Breach Susceptibility Indicator(BSI)

概要画面には、A〜Fの評価とは別に「Breach Susceptibility Indicator(BSI)」が表示されます。使っているソフトウェアや設定など、外から見える技術情報(technographic data)をもとに、情報漏えいの起こりやすさを0〜100で推定した指標です。A〜Fの評価とは逆に、数字が大きいほど危険です。

取引先BのBSIは91で、最も高い「Very High」に分類されています。全企業の平均は17(Very Low)なので、大きく上回っています。

一方、ランサムウェア被害に遭う可能性を表すRansomware Scoreは28(Very Low)です。同じ企業でも、指標によって評価が大きく異なります。

BSIを押し上げている要因

「View BSI Analytics」を開くと、Issue Typeごとに、全企業の基準値からBSIをどれだけ上下させているかが表示されます。

BSIへの影響が大きいIssue Type:基準値47から、問題ごとにどれだけ上下しているか
BSIへの影響が大きいIssue Type:基準値47から、問題ごとにどれだけ上下しているか
Issue Type内容影響
SSL/TLS Service Supports Weak Protocol古いSSL / TLSプロトコルを受け付けている+7
Site emits visible browser logsブラウザのコンソールにログが出ている+4
Unsafe Implementation Of Subresource Integrity外部から読み込むファイルの改ざん検知(SRI)が不十分+3
MySQL Service Observedデータベース(MySQL)がインターネットに公開されている+3
Content Security Policy Contains 'unsafe-*' DirectiveCSPに「unsafe-*」の指定が含まれている+2
TLS Service Supports Weak Cipher Suite弱い暗号スイートを受け付けている+2
Credentials at Risk For Up to Two Years過去2年以内に漏えいした認証情報が見つかっている+1

多くは設定の見直しで直せるものです。特に、データベースの公開と古いTLSは、実際の侵害につながりやすい問題です。

なお、この内訳では「基準値47+影響の合計18=65(High)」と計算されており、概要画面の91(分析画面では10月26日時点で90)とは一致しません。BSIはモデルによる推定値なので、数字そのものより、何が押し上げているかを見るのが実用的です。

多くの組織から監視されていても、指摘が直されなければスコアは変わりません。取引先からスコアを見られている前提で、指摘を一つずつ解消していくことが大切です。

実例(2026年10月時点)

Amalanceのスコア

比較として、当社(amalance.jp)のスコアは100点・A評価で、10個のFactorすべてで点数に影響する問題(High / Medium / Low)は0件でした。

amalance.jpのScore Factorsの画面(2026年10月)
amalance.jpのScore Factorsの画面(2026年10月)
Factor点数Findings
Network Security1000
DNS Health1001
Patching Cadence1000
Endpoint Security1000
IP Reputation1000
Application Security1001
Cubit Score1000
Hacker Chatter1000
Information Leak1000
Social Engineering1004

一部のFactorにFindingがありますが、いずれも点数に影響しない「参考情報」や「良い取り組み」に分類されるものです。

2026年10月時点

SecurityScorecard社について

会社情報
項目内容
社名SecurityScorecard, Inc.
設立2013年(事業開始は2014年)
本社米国ニューヨーク
創業者Aleksandr Yampolskiy(CEO、元CISO・CTO)、Sam Kassoumeh
従業員数約500名(推定)
利用組織3,300以上(Fortune 100の70%を含む、同社発表)
日本法人SecurityScorecard株式会社(東京都千代田区丸の内、代表取締役社長 藤本 大)

創業のきっかけは、CEOのYampolskiy氏がCISOをしていたころ、自社のセキュリティを同業他社や取引先と比べる方法がなかったことです。

融資で相手の信用スコアを確かめるように、
取引先のセキュリティも点数で確かめられるべきだ

創業時の考え方(要旨)

そう考えて、セキュリティの姿勢をA〜Fで評価する仕組みをつくりました。

日本では、2025年12月に管理画面の日本語対応を始めました。同社によると、英語以外の言語に対応したのは日本語が初めてです。問題(Issue)の詳細の日本語化は、2026年上半期に予定されていました。

資金調達・IR情報

SecurityScorecardは非上場企業です。株式公開(IPO)の申請や時期の発表はありません。そのため、決算などのIR情報は公開されていません。

時期内容
2021年3月シリーズEで1億8,000万ドルを調達。累計の調達額は約2億9,000万ドル。調達後の企業価値は約10億ドルと推定され、いわゆるユニコーン企業になりました。
主な投資家Silver Lake Waterman、Google Ventures(GV)、Intel Capital、Sequoia Capital、Evolution Equity Partners、Riverwood Capital、T. Rowe Priceなど
2025年9月HyperComply(カナダ)を買収。AIでセキュリティ質問票への回答を自動化するサービスで、Trust Center(信頼性ポータル)の機能もこの流れにあります。
2026年5月Driftnet(英国、2021年創業)を買収。インターネット全体をスキャンして、公開されている機器やサービスを特定する技術を持つ会社です。標準以外のポートで動くサービスやIPv6の資産まで捉えられるようにし、スコアの元になるスキャンの範囲を広げる狙いです。
保険会社との取り組み

セキュリティレーティングは、サイバー保険の引き受けや保険料の判断にも使われています。日本では東京海上日動が、国内の大手損害保険会社として早くからSecurityScorecardを取り入れています。

時期保険会社内容
2019年7月東京海上日動(日本)グループの東京海上日動リスクコンサルティング(TRC)がSecurityScorecard社と再販契約を結び、企業のサイバーセキュリティの状況を可視化するサービスとして提供を始めました。ドメイン名を入力するだけで、10のリスク要因を5段階で評価します(ScanNetSecurityの記事)。
2023年9月Measured Insurance(米国)スコアの高い企業がサイバー保険料の割引を受けられる仕組みを共同で発表しました(Help Net Security)。
2025年4月Willis(WTW、英国)サイバーリスクの定量化と保険のモデリングを高めるため、戦略的提携を結びました(Reinsurance News)。

なお、東京海上日動は2026年6月から「サプライチェーンサイバーリスク対策強化プログラム」を提供していますが、このプログラムとSecurityScorecardとの関係は、公開されている情報からは確認できませんでした。

ユーザーの評価
サイト評価件数
Gartner Peer Insights4.4 / 5278件
G24.3 / 592件
PeerSpot4.1 / 5(推奨したい人 92%)13件

Gartner Peer Insightsに掲載されています。製品名は「TITAN AI」(旧称:SecurityScorecard Platform)、カテゴリは「Third-Party Risk Management Technology Solutions(サードパーティリスク管理)」です。同業他社の製品との比較では、Bitsight、UpGuardと並べて評価を確認できます。

コラム

「外から使いたい」で開けたポートは、すべて見えている

オープンソースのAIエージェント「OpenClaw」(旧称:Clawdbot、Moltbot)は、インターネットに公開されたインスタンスが累計111万件以上見つかったと報告されています(SecurityScorecardのSTRIKEチームによる観測。2026年10月28日時点で、現在も稼働しているものは約4.7万件。DECLAWEDで随時公開されています)。

そのほとんどは、クラウドのサーバーで動かしているもの、またはルーターでポート開放して「外から使えるようにした」ものです。

これはAIエージェントに限った話ではありません。

ポート開放したものは、外からのスキャンで見つかる

ルーターでポート転送(Port Forwarding)を設定したり、UPnPで自動的にポートが開いたりすると、そのサービスはグローバルIPから誰でも到達できる状態になります。

※UPnP(Universal Plug and Play)は、LAN内の機器がルーターに「このポートを開けて」と自動で頼める仕組みです。

ゲーム機やビデオ会議などを設定なしで使えるようにする便利な機能ですが、次のような理由で危険があります。

  • 管理者の承認がいらない

    ポートを開けるかどうかは機器の側が決めます。ルーターは、頼まれれば認証なしで開けてしまいます。

  • 知らないうちに入口ができる

    管理者がポート転送の設定画面を見ても、手で設定したルールしか把握していないことがあります。気づいたときには、ネットワークカメラやNASの管理画面が外に公開されていた、ということが起きます。

  • 公開されやすいのは、守りの弱い機器

    UPnPを使うのは、カメラ、NAS、家電などの小さな機器が多いです。これらはアップデートが滞りがちで、初期パスワードのままのこともあり、外から狙われやすい機器でもあります。

  • マルウェアに悪用される

    LAN内の機器がマルウェアに感染すると、マルウェア自身がUPnPでポートを開け、外から入るための裏口や、攻撃の中継点を作ることがあります。

SecurityScorecardのようなサービスは、インターネット全体を定期的にスキャンしているため、こうした入口は必ず見つかります。

危険なサービス(リモートデスクトップ、NAS、カメラ、管理画面など)が公開されていれば、Network SecurityやCubit Scoreの評価が下がります。

もちろん、見つけるのはSecurityScorecardだけではありません。

攻撃者も同じようにスキャンしています。

ポート番号を変えても隠せない

「3389番ではなく33890番で公開しているから大丈夫」というのは通用しません。

標準以外のポートもスキャンされ、応答の特徴から「どのメーカーの、どの製品か」まで特定されます。

外から使いたいときは、VPNを経由させる

  • ポート転送の設定を見直し、不要なルールは削除する
  • UPnPは、必要がなければ無効にする
  • 社外から社内のサービスを使うときは、ポートを開けずにVPN(WireGuardなど)を経由させる
  • どうしても公開が必要なサービスは、接続元の制限、多要素認証、こまめなアップデートを組み合わせる

外から見える入口を減らすことが、スコアの維持にも、実際の侵害を防ぐことにもつながります。

まとめ

スコアを保つために見るべきところ

  • 公開するポートやサービスは最小限にする(Network Security、Cubit Score)
  • DNSとメールのなりすまし対策を整える(DNS Health)
  • 公開しているサーバーや機器は、すぐにアップデートする(Patching Cadence、Application Security)
  • 社内端末のマルウェア感染やスパム送信に気づける体制をつくる(IP Reputation)
  • Digital Footprintに他社の資産が混ざっていないか、定期的に確認する

ルーターやファイアウォールなど、インターネットとの境界にある機器は、外部から見える部分そのものです。ファームウェアを最新に保ち、管理画面やVPNを不要に公開しないことが、そのままスコアの維持につながります。

Previous PostUniFi NAS
Next PostRecorded Future