日本CTO協会は「技術」を軸に規模や業種の異なる様々な人や組織が集まっているコミュニティです。会員は本社団の活動内容、調査テーマについて参加、提案し、他の技術者・技術組織とともに成長する機会が得られます。ご興味のある方は法人会員向け申し込みフォームからお問い合わせください。

突然ですが情報漏洩時にかかる平均的な被害総額はいくらだと思いますか？

“Cost of a Data Breach Study 2020” によると答えは約4億933万円だそうです。コロナ禍におけるリモートワークの普及により、「情報漏洩を特定から食い止めるまでの時間が長くなる」、「被害の対応コストが増える」と回答した者は70%を超えており、情報セキュリティ対策の重要性が高まっています。最近では行政もセキュリティ強化に着目しており、日本政府は壁を一度突破されるとリスクが大きい「境界型」のセキュリティからゼロトラストアーキテクチャ（ZTA）の移行を検討しています (産経新聞 2020)。このように労力とコストがかかる情報セキュリティ対策に関して、本記事では進化を続けるセキュリティシステムのテクニックを紹介します。

前回の「デジタル企業ではすでに常識！100%自動化したソフトウェアデリバリー　世界のエンジニアに学ぶ（2）」に引き続き、世界のシニア技術者のおすすめ最新情報をまとめたレポート（Technology Radar）で紹介されていたテクニック・ツールを中心に紹介していきます。Technology RadarはCTO協会理事も着目してチェックするレポートであり、読者の皆様にとっても有益な情報源となるのではないでしょうか。これらのテクニックについて他の海外の論文、ブログ、レポートを交えて紹介し、ツールに関する本協会会員CTOからの評価やコメントも記載しておりますので、ぜひ参考にしていただき、実践してみていただけたら嬉しく思います。

---

目次

1. Technology Radar とは

2. コロナ禍におけるセキュリティシステムの重要性

3. セキュリティシステムのテクニック・ツール

3.1 スマートなセキュリティシステムのテクニック

3.1.1 ゼロトラストアーキテクチャ (Zero Trust Architecture)

3.1.2 コードとしてのセキュリティポリシー (Security Policy as Code)

3.1.3 エンドポイントセキュリティのためのサイドカー (Sidecars for Endpoint Security)

3.1.4 セキュリティ技術の3R (The Three Rs of Security)

3.2 スマートなセキュリティシステムのツール・プラットフォーム

3.2.1 Open Policy Agent (OPA)

3.2.2 ScoutSuite

3.2.3 Istio

4. 最後に

5. 引用文献

また、TechnologyRadarの各項目は更新されていくものであるため、更新・追加・新登場かどうかも直感的にわかるように表現されている。Newは新しく追加された項目、Movedin/outは以前紹介されたことがあるが所属リングが更新された項目、No Changeは以前紹介されている項目を指している。

あくまでもこれらの項目はThoughtsWorks社が独自の目線でピックアップし、分類したものである。それを考慮した上で、自社に採用できるツールを探すことはもちろん、次に定着しそうなツールはなんだろう、と言った別の目線でリングや新登場の情報を読み進めるのも面白いかもしれない。

ちなみにGoogle Sheetのテンプレートを使えば自分だけのRadarを作成することもできる（https://www.thoughtworks.com/radar/how-to-byor）

コロナ禍におけるセキュリティシステムの重要性

昨今はローカルホスト、複数のクラウドプロバイダ、さまざまなSaaSベンダーなど、セキュリティの境界線を越えたテクノロジーの利用が広がっており、ますます複雑化している。その上コロナの影響でリモートワークが増え、社員のホームネットワークやデバイスの脆弱性が問題視されている。ワークフロムホームのエンドポイントやクラウドサービスに対して、サイバー攻撃が増加しているという(RSI Security 2020)。

IBM Securityの後援を受けPonemon Instituteが実施した「Cost of a Data Breach Study 2020」によると企業の情報漏洩時にかかる平均的な被害総額は約4億933万円だった (IBM Japan Newsroom 2019)。昨年と比べて日本ではインシデント対応コストは増えており、ヘルスケア、エネルギー、金融、製薬業界など規制の厳しい業界ほどインシデント対応コストが高くなっていた (Brook 2020)。情報漏洩インシデントの80%は顧客の個人を特定できる情報（PII）の漏洩で、1レコードあたり約1万6千円と漏洩時の対応コストが最も高いカテゴリーだった。同レポートによると情報漏洩を特定して食い止めるまでの平均時間も280日と、企業にとってセキュリティ問題は時間と労力がかかることがわかる。

その一方で、AI、アナリティクス、オーケストレーションを含むセキュリティ自動化ソリューションとインシデント対応（IR）への備えなどにより大幅に被害が削減できることもわかっている (IBM Japan Newsroom 2019)。このようなセキュリティ・オートメーション・テクノロジーを全面的に導入した企業はそうではない企業と比べて情報漏洩時の対応コストを半分未満（前者のコストが平均約2億5,000万円に対し、後者のコストは平均6億2700万円）に抑えることができたという。

セキュリティシステムのテクニック・ツール

スマートなセキュリティシステムのテクニック

ThoughtsWorks社は昨今のウェブアプリケーションにおけるセキュリティ問題を把握するためにOWASP Top 10を参考にすることを勧めている (Komlo and Gomez 2016)。OWASP Top 10は開発者やウェブアプリケーションのセキュリティにおいて、基本的に意識するべき要素で、最も致命的なセキュリティリスクについての幅広いコンセンサスを表している。

Technology Radarではセキュリティに関する様々なテクニックを紹介しており、ゼロトラストアーキテクチャ(Zero trust architecture)などの動的できめ細かなセキュリティポリシーの適用を推奨している。そして、コードとしてセキュリティポリシーを扱うことや、エンドポイントセキュリティのためにサイドカーコンテナを利用することが効果的としている。以下ではこれらのテクニックに関して詳しく解説をしていく。

ゼロトラストアーキテクチャ (Zero Trust Architecture)

• Trial – New

近年サイバーセキュリティ対策で注目されているのがゼロトラストアーキテクチャ(ZTA)だ。ZTAは2010年にForrester Research IncのJohn Kindervag氏によって作られたモデルだ (Pratt 2018)。元来の境界線ベースのアーキテクチャでは物理的または仮想的に定義されたネットワーク内に「属する」者を自動的に信頼していた。ユーザーは認証を行い安全なネットワークの中にさえ入れば、様々なものにアクセスできる。しかしZTAでは、システムに接続しようとする全てのリソース（デバイス、インフラストラクチャ、サービス、データ、ユーザーなど）の認証と認可はアクセスを許可する前に動的に行われる。組織の内外に関係なくすべてのアクセスと通信を保護し、可能な限りセキュリティポリシーをコードとして実施し、脅威の継続的な監視と自動化された脅威緩和を実現する。ThoughtsWorks社はトラストゾーンやネットワーク構成に基づく静的で変化の遅いセキュリティポリシー管理から、一時的なアクセス権限に基づく動的できめ細かなセキュリティポリシーの適用へと移行するべきだと論じている (ThoughtWorks Technology Advisory Board 2020)。

最近では８月にアメリカ国立標準技術研究所（The National Institute of Standards and Technology （NIST))がZTAに関する新たなガイドラインを発表した (Rose et al. 2020)。NISTが提唱するZTAを実現するための前提を要約したものが以下である。

1.　ネットワークにアクセスするために使用されるすべてのデータソースとコンピューティングサービスはリソースとみなす

2.　ネットワークの場所（社内、公衆wifiなど）に関係なく統一された厳格な認証基準に合わせる

3.　個人の企業リソースへのアクセスは、時間制限を設けたセッション単位で付与する

4.　リソースへのアクセスはダイナミックな行動許可ポリシーによって決定され、リソース/データの機密性に基づいて変化する可能性がある

• クライアント ID ：ユーザーアカウント（またはサービス ID）と、企業がそのアカウントに割り当てた関連属性、または自動化されたタスクを認証する
• アセットステータス：インストールされているソフトウェアのバージョン、ネットワークの場所、要求の日時、以前に観察された動作、インストールされているクレデンシャルなどのデバイスの特性
• 行動属性：自動化された被験者の分析、デバイスの分析、および観察された使用パターンから測定された逸脱など
• 環境属性：リクエスト元のネットワークの場所、時間、報告されているアクティブな攻撃など

5.　企業は所有または関連するすべてのアセットの整合性とセキュリティの姿勢を監視し、測定する

• 企業はCDM(Continuous Diagnostics and Mitigation)(継続的な診断と脅威の緩和)または同様のシステムを確立し、必要に応じて修正を適用する必要がある。
• CDMとは、DHS(米国国土安全保障省)が、米国政府のサイバーセキュリティ問題に対してプロアクティブな対策を施すことが目的で2013年に策定された、FISMA（Federal Information Security Management Act of 2002）に適合した米国連邦および関連組織に対してのサイバー・セキュリティ・対策プログラムである (日本サイトラインシステムズ マーケティングブログ 2015)。

6.　すべてのリソースの認証と認可はアクセスが許可される前に動的に行われる

• アクセスを取得し、脅威をスキャンして評価し、適応し、継続的な通信の中で信頼性を継続的に再評価するという一定のサイクルが大切である。

7.　企業は資産、ネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、それをセキュリティ態勢の改善に利用する

最後に実際にZTAの仕組みを理解するために必要な構成要素を詳しく見ていこう。まずポリシー決定点(policy decision point (PDP))に含まれているポリシーエンジン(policy engine (PE)) とポリシーアドミニストレーター(policy administrator (PA))はデバイスやウェブトラフィックが安全であることを確認し、アクセスを許可したり取り消したりする (Vigliarolo 2020)。PEはアクセスを許可するかどうかを決定するもので、PAは実際に決定を実行してアクセスを許可する。

PEは、外部データソース（図の大きな円の外側）などを使用し、セキュリティポリシーに基づいて安全性を判断する。判断材料となりえるデータソースが以下である(Vigliarolo 2020)。

CDMシステム	アセットのセキュリティ状態に関する情報を収集し、必要に応じてデバイスのOSやセキュリティソフトウェアを更新し、その状態を PE に伝える。
業界コンプライアンスチェック	トラフィックとアセットが業界および組織のコンプライアンスルール（FISMA、HIPAA（Health Insurance Portability and Accountability Act）など）で動作していることを確認する。
脅威インテリジェンスフィード	あらゆる既存および潜在的な脅威に対する洞察を提供する。例としては、ランサムウェア、ウイルス、およびすべてのマルウェアや最新のセキュリティリソースへの攻撃などがある。
アクティビティログ	特定のアセット、IPアドレス、その他のソースからの気になる不審な動きを示す。
データアクセスポリシー	リソースへのアクセスを管理するすべての関連法規とガイドラインを指す。これらは各アセットごとに緻密に動的に調整されており、PEの意思決定プロセスの出発点としても機能する。
公開鍵基盤（public key infrastructure （PKI） ）	組織が発行した証明書をそのアセットに対して検証し、グローバルな証明書局に対して検証する。
セキュリティ情報・イベント管理システム（Security information and event management （SIEM） systems）	セキュリティに関するあらゆる情報を収集し、認証ポリシーの継続的な分析・修正に利用する。

これらの要素を集めることでZTAの仕組みを理解し、実装することが出来るだろう。裏ではこのように複雑なプロセスとなっているが、実際ユーザーが使用している際は既存のサイバーセキュリティとは異なると感じられるようなことはないだろう。

コードとしてのセキュリティポリシー (Security Policy as Code)

• Trial-New

セキュリティポリシーとは、脅威や混乱からシステムを保護するためのルールや手順のことだ。例えば、アクセス制御ポリシーは、誰がどのような状況下でどのサービスやリソースにアクセスできるかを定義して強制したり、ネットワークセキュリティポリシーは、特定のサービスへのトラフィックレートを動的に制限することができる。セキュリティポリシーをコード化することで、ポリシーの定義、自動的検証、自動的デプロイ、パフォーマンス監視などが一貫してできるようになる。Open Policy AgentなどのツールやIstioなどのプラットフォームは、柔軟なポリシー定義と実施メカニズムを提供し、コードとしてのセキュリティポリシーの実践をサポートする。上記のゼロトラストアーキテクチャ（ZTA）とも深い関わりがあるため、合わせて読んで欲しい。

エンドポイントセキュリティのためのサイドカー(Sidecars for Endpoint security)

• Trial (2019 Nov version)

昨今の私たちが構築している技術的なソリューションの多くは、複数の分散コンポーネントやサービスを持つ複雑なポリクラウドやハイブリッドクラウド環境で実行されている。しかし、サービス間通信のためのセキュリティ制御の強化は、サービスコードの複雑化や、ポリグロット環境でのライブラリや言語サポートの不足により、しばしば軽視されている。

ThoughtsWorks社はこのような状況下では、実装の初期段階で 2 つのセキュリティ原則を適用するという(ThoughtWorks Technology Advisory Board 2019)。1つ目は上記で説明したネットワークを信頼せず、常に検証するZTAの考え方だ。2つ目は特定のジョブを実行するために必要最小限の権限を与える最小特権の原則だ。エンドポイントセキュリティのためのサイドカーは、これらの原則を実装するために使用する一般的な手法で、サービスのAPI、データストア、またはKubernetesの制御インターフェースなど、すべてのコンポーネントのエンドポイントでセキュリティ制御を強制することができる。

その際使用するのがプロセス外のサイドカーである。プロセス外のサイドカーとは各サービスが同じ実行コンテキスト、ホスト、アイデンティティを共有してデプロイされ、スケジューリングされたプロセスやコンテナを指す。サイドカーは、通信の透過的な暗号化やTLS (Transport Layer Security) 終端などのセキュリティ機能に加えて、通話サービスやエンドユーザーの認証や認証を実装している。Open Policy AgentやEnvoyなどはこの技術を実装するツールである。

セキュリティ技術の3R (The Three Rs of Security)

• Assess (2018 May version)

セキュリティ技術の3RとはRotate, Repair and Repave（交替する、補修する、塗り替える）を指す。1つ目のRotateはデータセンターの認証情報を数分または数時間ごとに交替することを指す。2つ目のRepairはデータセンター内のすべてのサーバとアプリケーションを数時間ごとに、既知の安全な状態に補修することを意味する。コンテナで構築したシステムであれば、特定のソフトウェアにパッチを当てるのではなく、古いコンテナなどを破壊してスタック全体を修復し、既知の安全な状態から再構築することもできる。最後のRepaveは脆弱性のあるオペレーティング・システムとアプリケーション・スタックを、パッチが利用可能になってから数時間以内に一貫して修復することである。これらを組み合わせ、より速く動くことが安全性の向上につながるという (Smith 2017)。

データセンターにおけるセキュリティ上の懸念事項の最上位またはそれに近いものとしてAPT（Advanced Persistent Threat）が挙げられる。APTは、ネットワークへの不正アクセスを獲得し、長期間にわたって隠れていることができる。その目的は、データの窃盗、破損、身代金の要求などだ。これらの攻撃に必要な3つの要素をSmith氏(2017)は①時間、②漏洩または誤用された権限情報、③誤設定および/またはパッチが適用されていないソフトウェア、と分析する。時間が経てば、マルウェアが観察、学習、保存する機会が増える。権限情報は、他のシステムやデータへのアクセスを可能にし、場合によっては侵入ポイントにもなる。脆弱性のあるソフトウェアは、侵入だけでなく自由に動き回ったり、隠れたり、多くのデータを収集したりする余地を提供してしまう。つまりこれらの要素を1つまたはそれ以上取り除くことで、APT攻撃の成熟を防ぐことができるという。

セキュリティ技術の3Rは、最新のクラウドネイティブアーキテクチャの出現によって実現可能になっている。アプリケーションがコンテナとしてデプロイされ、完全に自動化されたパイプラインを介してビルドとテストが行われる場合、セキュリティパッチはワンクリックでパイプラインを介して送信される小さなリリースにすぎない。さらに、開発者は予期せぬサーバーの停止などの問題にも耐えられるアプリケーションを設計する必要があり、これはChaos Monkeyを実装した場合の環境と似ているといえる。Chaos MonkeyとはNetflixがオープンソースソフトウェアとして公開したものであり、エンジニアがインスタンスの障害に強いサービスを実装するために、本番のインスタンスをランダムに終了させる。このような技術をより広く応用するテクニック全般を指す「カオスエンジニアリング」は日本のエンジニア間でも話題となっており、例えばクックパッドは「Chaos Engineering やっていく宣言」を公開している。カオスエンジニアリングは「分散システムにおいてシステムが不安定な状態に耐えることの出来る環境を構築するための検証の規律」(Principles of Chaos Engineering 2018)と定義されており、セキュリティの強化にも応用できるテクニックといえるだろう。2018年のTechnologyRadarにてSecurity Chaos Engineering （セキュリティカオスエンジニアリング）というテクニックも紹介されている。本番ネットワークや他のインフラ（例えば、ビルド時の依存関係など）に意図的に演習としての攻撃を導入して、管理された条件下でセキュリティ障害を特定できる手順があるかどうかを確認する手法が有用だと説明している(ThoughtWorks Technology Advisory Board 2018)。しかし、セキュリティ問題に対するチームの感覚を鈍らせないように注意して使用する必要がある、とも追記してある。

またセキュリティ技術の3Rを理解する上でSecDevOpsの概念を取り入れるといいかもしれない。DevOpsには、すでに豊富なツールと自動化が含まれており、これらはセキュリティ技術の3Rを実装するために使用することができる。そもそもDevOpsとは、開発チームと運用チームを統合し、組織がより良いソフトウェアをより速く、より効率的に作成できるようにすることである。SecDevOps（「Rugged DevOps」や「Security at speed」と呼ばれることもある）はそのアプローチにセキュリティを組み込んだものだ (Komlo and Gomez 2016)。SecDevOpsの目標は、ワークフロー内で安全性の高いコーディング・セキュリティテスト・修正を自動化し、セキュアなソフトウェアをDevOps固有のアプローチの成果とすることだ (Arychuk 2015)。アプリケーション層のセキュリティを一度で完璧に作り上げることは大変難しいが、SecDevOpsを応用することで運用時のリスクを軽減することは可能である。このようにセキュリティ技術の3RをSecDevOpsのサブセットとして捉え、活用していくことができるだろう。まずはこれらのテクニックを実装する上でOWASP Dependency-Checkのようにパイプラインで信頼性の高い動作を提供する実績のあるツールから使い始めることをThoughtsWorks社は勧めている。

スマートなセキュリティシステムののツール・プラットフォーム

Technology Radarではコードとしてのセキュリティポリシーをサポートするツールがいくつか紹介されている。まだ知名度も低いツールかもしれないが、今後普及していく余地があり、より深掘りしたいという人はこれらのツールも試してみる価値があるかもしれない。

Open Policy Agent (OPA)　

Trial – Moved In/Out

Open Policy Agent (OPA) は分散型クラウドネイティブ・ソリューションの好ましいコンポーネントとして急速に普及している。OPAは、クラウドネイティブソリューションのさまざまなコンポーネントのポリシーを宣言、強制、制御するための統一されたフレームワークと言語を提供する。リソースをK8sクラスタにデプロイしたり、サービスメッシュでサービス間のアクセス制御を強制したり、アプリケーションリソースにアクセスするためのコードとしてのきめ細かいセキュリティ制御を行ったり、様々なシナリオで利用することができる。

ScoutSuite　

Trial – Moved In/Out

ScoutSuiteは、AWS、Azure、GCPなどのクラウドプロバイダー全体のセキュリティ態勢評価を提供するScout2（2018年にレーダーで取り上げられた）を拡張、アップデートしたツールだ。環境の設定データを自動的に集計し、ルールを適用して環境を監査する。プロジェクトでポイントインタイムのセキュリティ評価を行う際に非常に有用である。

Istio

Adopt – Moved In/Out

コードとしてのセキュリティポリシーの実践をサポートとするプラットフォームとしてIstioが紹介されている。Istioはもはやマイクロサービスのエコシステムを運用するためのデフォルトのインフラといっても過言ではないだろう。サービスディスカバリ、トラフィック管理、サービス間およびオリジン間のセキュリティ、可観測性（テレメトリや分散トレースを含む）、ローリングリリース、復元力などの豊富な機能を備えている。最新のリリースでは、インストールの容易さとコントロールパネルのアーキテクチャにより、ユーザーエクスペリエンスが向上している。自社でIstioやKubernetesインスタンスを運用するには十分な知識と社内リソースが必要であると理解しつつも多くのクライアントに運用品質の高い大規模マイクロサービスを実装するためのハードルを下げてきた。ThoughtsWorks社では これまで使ってきたサービスメッシュ（マイクロサービス間のサービス間通信を容易にするための専用インフラストラクチャレイヤー）のテクニックのメインの実装としてIstioを採用しているという(ThoughtWorks Technology Advisory Board 2019)。

最後に

本記事ではセキュリティにまつわる様々なテクニック・ツールを紹介しました。複雑化するシステム・サービスの管理にはセキュリティの注意が欠かせません。少しでもDXを推進する皆さんの参考になればと思います。最後に本記事のまとめです。

「セキュリティに関してはリモートワークの普及も視野に入れ、よりリスクの低いZTAの導入を視野に入れる」

「コードとしてセキュリティを扱うことで自動化、一貫性、リスクの軽減を実現する」

「ZTAなどの実装にはエンドポイントセキュリティのためのサイドカーを使用することができる」

「セキュリティ技術の3Rを用いることで攻撃の隙を与えず、リスクを軽減できる」

引用文献

arvindpdmn 2018 Three Rs of Security. Devopedia. https://devopedia.org/three-rs-of-security, accessed October 16, 2020.

Arychuk, Stevan 2015 SecDevOps: Injecting Security Into DevOps. New Relic Blog. https://blog.newrelic.com/technology/secdevops-rugged-devops/, accessed October 16, 2020.

Brook, Chris 2020 What Does a Data Breach Cost in 2020? Text. Digital Guardian. https://digitalguardian.com/blog/what-does-data-breach-cost-2020, accessed September 29, 2020.

Forrester  N.d. Zero Trust Is Replacing “Trust But Verify.” Forrester. https://go.forrester.com/government-solutions/zero-trust/, accessed August 17, 2020.

Komlo, Chelsea, and Gomez, Maria  2016 Incorporating Security Best Practices into Agile Teams. ThoughtWorks. https://www.thoughtworks.com/insights/blog/incorporating-security-best-practices-agile-teams, accessed November 6, 2020.

Pratt, Mary K. 2018 What Is Zero Trust? A Model for More Effective Security. CSO Online. https://www.csoonline.com/article/3247848/what-is-zero-trust-a-model-for-more-effective-security.html, accessed August 17, 2020.

Principles of Chaos Engineering 2018. https://principlesofchaos.org/, accessed October 16, 2020.

Rose, Scott, Oliver Borchert, Stu Mitchell, and Sean Connelly 2020 Zero Trust Architecture. National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf, accessed August 14, 2020.

RSI Security 2020 What Is the NIST Zero Trust Architecture? RSI Security. https://blog.rsisecurity.com/what-is-the-nist-zero-trust-architecture/, accessed August 17, 2020.

Smith, Justin 2017 The Three R’s of Enterprise Security: Rotate, Repave, and Repair. Medium. https://builttoadapt.io/the-three-r-s-of-enterprise-security-rotate-repave-and-repair-f64f6d6ba29d, accessed October 16, 2020.

ThoughtWorks Technology Advisory Board
2018 Technology Radar | An Opinionated Guide to Technology Frontiers　Vol.19.

2019 Technology Radar | An Opinionated Guide to Technology Frontiers　Vol.21.

2020 Technology Radar | An Opinionated Guide to Technology Frontiers　Vol.22. https://www.thoughtworks.com/radar?utm_source=en&utm_medium=pdf&utm_campaign=techradar-vol22, accessed August 3, 2020.

Vigliarolo, Brandon 2020 Zero Trust Security: A Cheat Sheet. TechRepublic. https://www.techrepublic.com/article/zero-trust-security-a-cheat-sheet/, accessed August 17, 2020.

産経新聞 2020 政府、サイバーセキュリティ対策に「ゼロトラスト」導入へ. ITmedia NEWS. https://www.itmedia.co.jp/news/articles/2009/28/news051.html, accessed October 9, 2020.

日本サイトラインシステムズ マーケティングブログ 2015　DHS CDM(1/). https://mktgblog.sightlinesystems.co.jp/2015/11/dhs-cdm-01.html, accessed September 29, 2020.

執筆担当者

日本CTO協会　竹谷真帆

有志

C Channel株式会社 執行役員　小野邦智
株式会社シンシア 代表取締役社長　徐聖博

日本CTO協会

担当理事 名村卓(株式会社メルカリ 執行役員)
PM 松下清隆

---

日本CTO協会ではメールマガジンに登録いただいた方に定期的に最新レポートの情報や本協会の活動をお届けしています。