FAQ: ソフトウェアセキュリティ

Lokadは何よりもまずサプライチェーンの専門家であり、私たちの主要な目標は技術的な独創性を通じて卓越したサプライチェーンの意思決定を提供することです。とはいえ、私たちは毎日重要な財務データを扱っているため、ソフトウェアプラットフォームのセキュリティは最重要事項であり、極めて真剣に取り組んでいます。セキュリティを官僚的な後付けの考えとして処理するのではなく、計画的かつ積極的な対応を重視する原則的なアプローチ―それは特定のソフトウェア設計、人材配置、研修の選択に裏付けられています。

対象読者：IT部門
最終更新日：2023年9月21日

セキュリティの原則

エンタープライズソフトウェア界隈で最も有害な幻想の一つは、セキュリティがチェックリスト、認証、さらにはあらゆる種類の官僚的な手続きによって対処できるという考えです。残念ながら、セキュリティ上の問題の細部は常に変動しており、不正な意図を持つアクターがソフトウェアや人（あるいはその両方）を悪用することで問題が発生します。したがって、セキュリティは一般原則の合理的な適用を通じてのみ対処可能です。

設計による安全性

私たちは、設計がソフトウェアセキュリティにおいて最も過小評価されがちな側面の一つであると信じています。ここでいう設計とは、ソフトウェアを開発するために行われた根本的な意思決定を意味します。企業が下す設計上の決定は、特に攻撃対象面に関して、セキュリティに大きな影響を及ぼします。合理的なソフトウェア設計により、Lokadは一連のセキュリティ問題のカテゴリ全体を排除してきました。例えば、LokadはSQLデータベースではなく、単純なBLOBストレージを受動的なストレージ層として使用しています。この選択だけで、SQLインジェクション攻撃などのセキュリティ問題の全グループを防止することが可能となります。同様に、私たちの永続化層はすべて追記専用になっています。これは、既存のデータに変更を追加していくバージョン管理に似ており、データ全体を書き換えることはありません。すべての変更は追跡され、元に戻すことができるため、攻撃者を含む第三者によるデータの削除やログの改ざんを非常に困難にしています。

ほとんどのエンタープライズソフトウェアベンダーは、コアとなる設計上の選択が彼らのソフトウェア製品の基盤であるという事実を認めようとしません。その結果、彼らのセキュリティ問題は絶え間なく発生します。例えば、エンタープライズソフトウェアの必須要件である構成可能性が、PythonやJavaScriptのような汎用プログラミング言語を通じて提供される場合、セキュリティ問題は必然的に発生します。これは、汎用プログラミング言語を完全に安全にすることがほぼ不可能であるためです。対照的に、Lokadはすべての構成可能性をDSL（ドメイン特化型プログラミング言語）であるEnvisionを通して統制するという意識的な設計選択を行いました。Envisionは、設計上、OS（オペレーティングシステム）やそのサブシステム（ファイルシステムなど）と直接対話する機能を持たないため、より安全です。

文化による安全性

どんな技術であっても、ましてやプロセスでさえ、人々が関心を持たなければソフトウェアを安全にすることはできません。したがって、Lokadではその技術とプロセスの両方に対して、本物の関心を持ってもらえるよう努めています。エンタープライズソフトウェアの場合、対象が抽象的であり、人々の個々の視点や動機から切り離されがちであるため、これは非常に困難な課題となります¹。

まず第一に、Lokadは可能な限りマーケティングメッセージを事業の現実に合わせています。これにより、好意的な反応であろうと批判であろうと、真実を伝えることができます。これは、実情と対外的なコミュニケーションとの間に不合理な乖離が生じる多くのエンタープライズベンダーとは対照的です²。後者の場合、現実と伝えられる内容の乖離に気付く鋭敏な従業員は関心を失い、その無関心が自己満足を生み、結果としてセキュリティ問題に繋がります。しばしば、そのような従業員は会社を去り、結果として「騙されやすい」人々だけが残ってしまうのです。騙されやすさは、無関心と同様、セキュリティ上好ましい特性ではありません。

次に、Lokadは従業員の間に、技術的な面も非技術的な面も含めた事業全体やセキュリティに関する好奇心と健全な懐疑心を育んでいます。これにより、従業員は慣行の見直しや更新に柔軟に対応できるようになります。この柔軟性は、不正な意図を持つアクターが次々と創造的な攻撃手法を考案する可能性を予見する上で有用です。幸いなことに、この考え方は、サプライチェーンにおいては必ずしも犯罪的でない悪意ある行動が一般的であるため、非常に望ましいものとなっています³。

研修による安全性

私たちは、すべてのスタッフにサイバー攻撃の脅威とその緩和方法について理解を深めてもらうため、積極的に研修を行っています。設計や文化とは異なり、セキュリティ研修は大部分が上からの指示によるものです。ボトムアップの考え方にも一定の価値はありますが、この種の研修は多くのコンピューターセキュリティリスクに対して本質的に脆弱です。つまり、たとえ人々が何かをしてはいけないと訓練されていても、誰もその行動を絶対に行わないと仮定することはできません⁴。そのため、私たちはより厳格なアプローチを採用しています。研修の一環として、LokadではUSBフラッシュドライブやその他のUSBデバイスの使用を控えるよう推奨しており、これらが機器を危険にさらす可能性があるからです。また、可能な限り二要素認証の利用を徹底し、従業員にはワークステーション上で必要最小限の権限で作業するよう指導しています。さらに、社会工学の手法がいかにして非常に優秀な人々をも騙し得るかについても全員が認識するよう努めています。

より一般的には、セキュリティ研修は、ソフトウェアやプロセスが不正な意図を持つ者によってどのように転用・改ざんされ得るかに対する認識を高めることに重点を置いています。そのため、こうした精緻な攻撃を防ぐために必要な研修の範囲や技能、ノウハウを考慮すると、Lokadでは同規模の他社と比べ非常に少数のインターンしか採用していません。要するに、長期的に安定した、高度な訓練を受けたチームに賭けることを好んでいるのです。

よくある質問 (FAQ)

1. 取組み

1.1 セキュリティ保証はありますか？

はい。セキュリティ保証とは、セキュリティ強化、セキュリティテスト、脆弱性管理など、さまざまな取り組みを包括する用語です。Lokadにおけるセキュリティ強化は、何よりもまず設計によって実現されています。特定の設計上の選択により、一連の脆弱性カテゴリを排除し、その結果、強化そのものの必要性をなくしています。例えば、Lokadはリレーショナルデータベースのような「プログラム的」なストレージ層に依存するのではなく、単純なキー・バリューストアを採用しています。これにより、全てのSQLインジェクションの手段が排除されます。さらに、セキュリティテストは自動化された方法と手動による方法―例えば第三者によるペネトレーションテスト―と、多様な手法で実施されています。脆弱性管理については、バグバウンティポリシープログラムを実施し、修正が迅速に展開されるように広範な自動化されたリリース管理プロセスを整えています。

1.2 ISO 27001（ISMS）および/またはSOC 2に準拠していますか？

いいえ。これらの認証は、ソフトウェア企業のセキュリティを低下させる誤った方向への逸脱であると私たちは確信しています。これらのコンプライアンスプロセスは、ソフトウェアのセキュリティに必要なものとは正反対の官僚的な考え方を強調し、書類作成や委員会の設置を要求します。率直に言えば、書類や委員会がソフトウェアセキュリティに実質的な効果をもたらすとは到底言えず、Lokadでは全く採用していません。

ソフトウェア業界では、セキュリティは通常、必要な作業を抑え、ソフトウェアセキュリティを専門とするエンジニアの努力を活用することで達成され、非専門家による追加のチーム作りは行われません。例として、HeartbleedやLog4Shellのような重大なサイバーセキュリティの惨事が挙げられます。これらの災害は、何千もの「認証済み」ソフトウェア企業が、第三者コードの校正―しばしば問題の根本原因―を優先していたならば、防げた可能性があります。

全体として、これらの認証は企業を誤った安心感（比喩的にも文字通りにも）に陥らせるマーケティングの策略だと考えています。

1.3 OWASPのプラクティスに従っていますか？

はい。OWASPは、ガイドを通してソフトウェアによく見られる脆弱性に対する広範なチェックリストを提供しています。これは、LokadのエンジニアがOWASPで特定された問題からソフトウェアを守るために活用する、高品質で包括的なリストです。しかしながら、Lokadの設計上の選択により、OWASPで強調される一般的な脆弱性の多くが排除されています。例えば：

パスワード管理: SSO（シングルサインオン）機能によって認証を委任することで、Lokadはもはやパスワードを「管理」する必要がなくなり、パスワードに関するチェックリストは不要となります。

ロギング: Lokadが採用しているイベントソーシング設計では、すべてのアクションが必然的に記録されます。もしアクションが記録されなければ、そのアクションはシステム上、存在しなかったとみなされ、ロギングに関するチェックリストの大部分が無効となります。

データベースセキュリティ: Lokadの永続化層はリレーショナルデータベースを含まず、イベントソースとキー・バリューストアという、プログラム的でない二つのコンポーネントのみで構成されています。この設計選択により、データベースに関するチェックリスト全体が無効化されます。

より一般的には、可能な限り、そもそもエラーを誘発しやすい設計パターンを避けることを好んでいます。

1.4 GDPRに準拠していますか？

はい。しかし、Lokadが提供するサプライチェーン最適化には個人データは必要ありません。個人データは資産ではなく負債と考えているため、クライアントには個人データを弊社に転送しないよう強く推奨しています。この推奨は通常、契約上の合意事項の一部となっています。個人データを保持せず、結果として個人データの処理を行わないことで、GDPRや類似の規制に関連する保護プロトコルや懸念事項を大幅に排除しています。

1.5 Lokadのソリューションにおける、個人を特定可能な情報（PII）へのアクセスを伴うすべてのサードパーティサービス/ソリューションは、データ保護責任者（DPO）の要件に準拠していますか？

はい。しかしながら、1.4 GDPRに準拠していますか？で述べたように、Lokadが提供するサプライチェーン最適化には個人データは必要ありません。したがって、クライアントには個人データを弊社に転送しないよう強く推奨しています。

なお、Lokadのソリューションでは、PIIデータにアクセスできるサードパーティの数は非常に限られており、2023年1月現在、このリストはMicrosoft Azureに限定されています。

1.6 セキュリティに関するベストプラクティスに従っていますか？

はい。つまり、業界全体で何が「最良のソフトウェアセキュリティプラクティス」となるかについて明確な合意がない中、私たちは慎重な選択を行っています。ソフトウェアセキュリティは常に進化し、新たな脅威や攻撃ベクトルに適応する性質があるため、第三者に丸投げするのではなく、クライアントにとって最適な対策を自ら定義しています。これにより、流行しているという理由だけで従うのではなく、利用可能な良いプラクティスを柔軟かつ効果的に取り入れることが可能となっています。

1.7 定期的にペネトレーションテストを実施していますか？

はい。計画的なものと突発的なものの両方のペネトレーションテストを実施しています。計画的なテストは、契約に基づき、大口クライアントが主要なソフトウェアベンダー（Lokadを含む）のペネトレーションテストのために専門会社を雇用する形で実施され、Lokadのエンジニアリングチームとこれらのセキュリティ専門家との間である程度の調整が行われます。突発的なテストは、一般公開のバグバウンティポリシープログラムの一環として、フリーランスのセキュリティ専門家がシステムの潜在的なエクスプロイトを探す形で実施されます。

1.8 定期的に外部監査を実施していますか？

いいえ。しかし、クライアントが費用を負担するのであれば、外部監査を受けることには前向きです。多くの大口クライアントとの契約には、外部監査の条項が含まれています。2023年1月現在、クライアントが行ったペネトレーションテストでは、外部監査を実施するほどの問題は発見されていません。

1.9 事業継続計画はありますか？

はい。Lokad が対処した最大の緊急事態は、会社自体が仮に業務を停止するというケースです。Lokad は SaaS ソリューションとして運営されていますが、大手クライアントの一部には、契約書にコードベースの完全なスナップショットをリクエストできる条項が含まれています。これらのスナップショットは、合意された第三者のエスクローに預けられ、万一 Lokad が業務を停止した場合、クライアントは自動的にエスクローに保管されたコードベースへのアクセス権と、Lokad サービスの自社インスタンスを再構築するための寛容なライセンスを得ることになります。

1.10 危機コミュニケーション計画はありますか？

はい。すべてのクライアントには、彼らの組織内の連絡窓口を特定しています。Lokad 側では、少なくとも2名の従業員（通常はサプライチェーンサイエンティスト2名）が配置され、クライアントに緊急のメッセージを伝える役割を担っています。実際、私たちが直面する危機のほとんどはソフトウェアのセキュリティ問題ではなく、サプライチェーンに関するものです ― クライアントから提供されるデータに基づいて Lokad が識別する緊急事態です。セキュリティイベントの場合、このチャネルを用いてクライアントに迅速に情報が伝わるようにしています。

1.11 クライアントの IT システムの安全をどのように確保していますか？

私たちは、Lokad がクライアントの IT システムにアクセスしないことを強く推奨します。クライアントの IT システムは、Lokad からデータをプッシュおよびプルするだけであるべきです。このアプローチは、Lokad でのセキュリティイベントがクライアントの IT システムに拡大する可能性を軽減することを意図しています。さらに、SSO（シングルサインオン）プロセスの使用も強く推奨します。これにより、Lokad にアクセスするために使用されるパスワードが（何らかの方法で）傍受され、その後クライアントの IT システムの一つが侵害されるという仮定のシナリオを排除できるためです。

1.12 どのようにネットワークを保護していますか？

私たちの設計はゼロトラストアーキテクチャを採用しており、これは常に適切な人物のみがデータにアクセスできることを意味します。単にネットワーク上に存在するだけでは、自動的にステータスや特権が付与されることはありません（この点は Authentication 2.1 で詳細に説明されています）。そのため、ネットワークセキュリティに十分配慮するとともに、初期段階でネットワークに関連する攻撃対象範囲を可能な限り小さくすることを確実にしています。

Lokad は 2 つの注目すべきネットワークを利用しています。1 つ目は、当社のソリューションのホスティングに使用される Microsoft Azure です。Microsoft Azure のネットワークのセキュリティは完全に Microsoft に委ねられています。基本的なロードバランサを超える、Microsoft Azure が提供する「高度な」ネットワーキング機能は使用していません.

2 つ目は、パリにある当社本社のローカルネットワークです。ローカルネットワークのセキュリティは、Lokad のエンジニアリングチームによって内部的に管理されています。当社のローカルネットワークは、生産環境に寄与するいかなるコンポーネントやシステムもホストしていません.

1.13 ソリューションに統合されているすべてのコンポーネント（サードパーティのものを含む）およびツール（オープンソースのものを含む）が、開発および本番環境で合法的に使用できることを保証しますか？

はい。Lokad は、他の多くのエンタープライズソフトウェアベンダーと比較して依存関係が非常に少ないです。主要な依存関係はすべて信頼性が高く、広く使用されているオープンソースプロジェクト（例：Microsoft の .NET、Facebook の React）です。このため、この点に関する内部監査プロセスは非常にシンプルなものとなっています.

1.14 セキュリティに関する組織やプロセスの大幅な変更をどのように管理していますか？

Lokad は最初から合理的なセキュリティ設計の選択と実践を採用しているため、大小を問わず変更がセキュリティに影響を与える（仮にでも）ことは稀です。Lokad の歴史において、セキュリティの観点から本当に重大と考えられる出来事は、2010 年の Microsoft Azure への移行、2012 年の委任認証の導入（クライアントと従業員の両方に対して）、および 2022 年の内部における Google 認証から Microsoft Azure AD への移行の 3 件のみです.

これらの各事象について、Lokad のソフトウェアエンジニアリングチームが数か月前から移行の準備を行っていました。すべての Lokad 従業員の準備が整うよう、予定された変更の前に関連する研修資料と研修セッションが実施されました。最後に、各移行後には従来の「パス」を排除することを確認しており、これは Lokad の標準的な慣行です.

2023年1月現在、今後の大幅な変更は計画しておりません。もしそのような変更が行われる場合でも、ほぼ確実に同様の方法で進めることになるでしょう.

1.15 契約終了時の対応はどのように管理していますか？

契約書には、クライアントと合意の上で、契約終了時の解約プロセスが詳細に記載されています。解約プロセスは、最終的にクライアントのデータが完全に削除されることで終了します。この解約プロセス自体がセキュリティリスクとなるため、各クライアントと協議の上で決定され、そのためケースによって若干の違いが生じることがあります。セキュリティの観点から、悪意ある行為者がクライアントになりすまして早期解約を引き起こし（クライアントの業務に混乱をもたらす）可能性があるためです。これを防ぐために、Lokad とクライアントは合同で、契約上の拘束力を持つ、容易にソーシャルエンジニアリング攻撃に対して脆弱でないプロセスの採用に努めます。このプロセスには通常、書面による確認と必須の遅延が含まれます.

1.16 Lokad のライセンス戦略、関連するコストモデル、および年間保守費用モデルはどのようになっていますか？

Lokad は通常、プラットフォームの運用コストに対応する定額の月額料金と、クライアントに専属のサプライチェーンサイエンティスト（すなわち Lokad のエンジニア）によるサービスに対応する定額の月額料金を請求します。詳細はクライアントと Lokad 間のサービス契約で交渉および明記されます。この二つの料金は、Lokad の「オールインクルーシブ」パッケージを表しています。追加の保守料金、ライセンス料金、サードパーティの統合業者やコンサルタント料金等は一切発生しません。パッケージには、契約上共同で交渉される範囲とスケールの制限があります.

1.17 ライセンス、サービス、サポート、メンテナンス、およびトレーニングに関する Lokad の利用規約を提供できますか？

はい、クライアントの要請があれば、「ベースライン」契約を表す契約書のテンプレートを提供することができます。ただし、状況はサプライチェーンイニシアチブの規模、対象国、および Lokad に期待されるサービスの範囲に大きく依存して大きく異なります。そのため、可能であれば、見込みクライアントとの最初の打ち合わせを行い、検討中のサプライチェーンイニシアチブの詳細を明確にすることを好みます。これにより、状況に最も適した契約フレームワークを構築することができます.

1.18 トレーニング（現地/オンライン）を提供していますか？

はい、Lokad は現地トレーニングとリモートトレーニングの両方を提供しています。これらのセッションの詳細は、契約の一部として交渉されます。さらに、Lokad には包括的な public technical documentation と、詳細な一連の サプライチェーン講義 が存在します。これらの講義では、Lokad の技術とサプライチェーンに対する考え方が取り上げられています.

1.19 Lokad のシステムは、関連する法規制および地域の基準（例：ISO）を満たしていますか？

はい、Lokad は関連する基準に沿って運用されています。しかし、Lokad はサプライチェーンの予測的最適化を提供しており、そのため直接的にオペレーションを管理しているわけではありません。私たちの影響力は主に間接的なものであり、通常はリソースの配分の最適化を通じて発揮されます。したがって、ISO の基準はここでは関連性がありません（つまり、Lokad には適用されません）.

1.20 ファイアウォール、プロキシデバイス、またはネットワーク自体のような、ネットワーキングレベルでのマルウェア保護は組み込まれていますか？

詳しくは Practices 1.12 を参照してください.

1.21 ソフトウェア開発プロセスに統合された脅威評価は含まれていますか？

はい。これが、私たちがセキュリティの懸念を「設計段階から」対処することを重視する主な理由です。設計段階で脅威の全体カテゴリを排除することで、全体の脅威評価プロセスをより管理しやすくしています。脅威評価は「サプライチェーン攻撃」もカバーしており、これがまた、ソフトウェアスタックにおけるサードパーティの依存関係の最小化に強い重点を置く理由の一つです。なぜなら、依存関係は本質的に攻撃対象範囲を拡大するからです.

1.22 インシデント管理プロセスは年に少なくとも一度はリハーサルされていますか？

はい。インシデントには様々な種類があります。その中でも最も頻繁に発生するのは、クライアント企業自体が侵害されるケースです。ランサムウェアの場合、Lokad のデータが誤って唯一アクセス可能なデータセットとなることがあります。なりすましの場合、盗まれた認証情報を用いて Lokad アカウントへの不正アクセスが試みられることがあります。各インシデント管理プロセスの詳細は、クライアント企業と共同で策定され、通常、マネージドアカウントを選択したクライアントの場合は、そのアカウントを担当する Lokad のサプライチェーンサイエンティストによって監督されます.

1.23 リスクおよび脅威マッピングは年に少なくとも一度は見直されていますか？

はい。ただし、これらの見直しは通常、年間を通じて定期的に実施されています。これらのレビューは、ソフトウェア業界における顕著なセキュリティ侵害など、重要な出来事に促されて行われることが多いです.

1.24 ソリューションの可用性、品質、および/またはセキュリティに影響を及ぼす可能性のある支援機能に対してもリスク評価が行われていますか？

はい。しかし、Lokad プラットフォームは、本質的に Microsoft Azure が提供する Blob Storage や Linux VM など、いくつかの主要な基盤以外の「支援機能」に依存しないモノリス型です.

1.25 システムプロセスの実行のために、必要なアクセス権のみを持つ専用のシステムアカウントが作成されていますか？

はい、システムプロセスの実行には適切なアクセス権を持つ専用のシステムアカウントが使用されます。Lokad は systemd サービスという形でデーモンを利用しており、これらは常に可能な限り少ない特権を持つユーザーとして稼働しています.

Lokad は SQL データベースを使用していませんが、プラットフォームはスケジュールされたプロセスやトリガーされたプロセスのアクセス権を決定するために、ロールベースのシステムを採用しています。これらのプロセスは「システム」プロセスではなく「ユーザーランド」として分類されます.

1.26 経営陣によって承認された、エンタープライズリスクマネジメント（ERM）プログラムの要件を定義する正式なリスクガバナンス計画はありますか？

はい、経営層によって承認された正式なリスクガバナンス計画が存在します.

この計画は、エンタープライズリスクマネジメント（ERM）プログラムの要件とガイドラインを概説しており、組織全体のリスクを体系的かつ一貫性のある方法で特定、評価、管理、監視するよう設計されています.

また、リスクガバナンス計画は定期的に見直され、組織の目的や変化するリスク環境に沿ったものとなるよう更新されています。さらに、ERM プログラムの実施状況とその効果は、継続的な監視と支援を確保するために、定期的に経営陣および関連するステークホルダーに報告されます.

1.27 経営陣によって承認され、関係者に周知された物理的セキュリティプログラムが存在し、その維持と見直しのための担当者が任命されていますか？

はい、経営層により承認された包括的な物理的セキュリティプログラムが存在します。このプログラムは、すべての関係者に十分に周知され、認識と順守が確実に行われるようになっています.

加えて、プログラムの有効性と適合性を確保するために、その維持、更新、および定期的な見直しの責任者が任命されています。この責任者は、各チームや部門と連携して新たな物理的セキュリティの懸念に対処し、プログラムがベストプラクティスおよび当社の組織目標に沿うようにしています.

1.28 システムが設置される施設の場所を決定する前に、物理的および環境的リスクの評価が実施されていますか？

はい、物理的および環境的リスクの評価は、システムの設置場所を決定する際の意思決定プロセスの不可欠な部分です。当社のシステムは Microsoft Azure のデータセンターに配置されているため、Microsoft の厳格な施設選定および評価プロセスの恩恵を受けています。Microsoft Azure は、データセンターの設置前に、物理的および環境的リスクを含む潜在的なリスクを包括的に評価します。彼らの選定プロセスには、自然災害の可能性、アクセス性、インフラの安定性などの要因の分析が含まれています.

Azure のデータセンターを利用することで、これらの評価が包括的に実施され、当社のシステムに対して最高レベルの物理的セキュリティおよび環境耐性が確保されていると確信しています.

1.29 内部のコンプライアンスおよび倫理プログラムが文書化されていますか？

はい。ただし、「倫理」はトップダウンで強制するものではないと考えています。このようなアプローチは、必ずや本来の目的に反する望ましくない結果を生むものです.

有名な例として、Enron は文書化された倫理規範を持っていました。この規範は、尊敬、誠実、コミュニケーション、卓越性を強調していました。しかし、2001年に明るみに出た Enron スキャンダルでは、同社が大規模な会計不正に関与していたことが判明し、これは明らかにその倫理規範の原則に反するものでした。したがって、Enron の公言された文書上の倫理と実際のビジネス慣行や企業文化との間には、完全な乖離が存在していました.

このため、Lokad は従業員がクライアントに真摯に関心を持つ機会を確実に得られるよう注力しています。「私たちは正しいことをしているのか？」という問いが私たちのモットーの一つです。私たちの見解では、コンプライアンスと倫理は、特定のプログラムの結果ではなく、適切な企業文化の副産物です.

1.30 未解決の規制やコンプライアンスの問題の解決を追跡する責任を持つ、内部監査、リスク管理、またはコンプライアンス部門、もしくはそれに類する管理監督機能は存在しますか？

はい。Lokad は内部監査、リスク管理、またはコンプライアンス専任の独立した部門を持つほど大規模ではありませんが、これらの分野を確実に優先しています。これらの領域に関する専門知識を持つ担当者を任命し、これらの重要な責任の処理と監督を担当させています.

これらの人々は、Lokadの最上位経営層へ直接報告し、未解決の規制やコンプライアンスの問題が最優先事項として扱われ、当社組織の最上位レベルで必要な監視が行われることを保証します。

1.31 経営陣によって承認され、適切な関係者に伝達され、その保守および見直しのためにオーナーが指定された無線ポリシーまたはプログラムはありますか？

はい、Lokadには経営陣によって承認され、すべての関係者に伝達された明確な無線ポリシーがあり、遵守が確実にされるようになっています。このポリシーは、従業員専用のWi-Fiネットワークと、ゲスト専用のWi-Fiネットワークという2つの独立かつ隔離されたネットワークを区別しています。この区別により、ゲストや訪問者に接続性を提供しながらも、主要な業務の安全性が維持されます。

ただし、当社の主要な接続手段は、優れたパフォーマンスと強化されたセキュリティのためにEthernetであることに留意すべきです。Wi-Fiネットワークは主に会議に対応し、特定のシナリオで柔軟性を提供するために設けられています。

さらに、このポリシーの保守と定期的な見直しを担当するオーナーが指定されており、変化するニーズや課題に対処するために最新かつ効果的な状態が保たれるようにしています。

2. 認証

2.1 すべてのアクセスに対して認証を強制しますか？

はい。クライアントデータおよび／またはソリューションの重要な機能にアクセスするには、事前の認証が必要です。ただし、必要に応じて、一部の接点は認証の対象外となる場合があります。例えば、ログインウェブページにアクセスする際は、認証前のアクセスが不要です（このウェブページ自体が認証を目的としているためです）。

全体として、認証を必要としない技術的エンドポイントは非常に少なく、通常はプラットフォームの計測目的の一部（例：機器が稼働しているかを確認するためだけのエンドポイント）として存在します。なお、認証を必要としないエンドポイントは、機密性の高いデータ、ましてや実際のクライアントデータを露出することはありません。

2.2 すべてのリモートアクセスが安全であることを要求しますか？ウェブ接続に対してHTTPSを強制しますか？

はい。リモートアクセスを安全にするとは、適切な認証、適切な認可、および通信路自体の暗号化を行うことを意味し、これらすべてを当社は強制しています。この規定は、クライアントユーザーとLokadの従業員の両方に適用されます。Lokadのエンジニアリングチームにおいても、生産システムへの「安全でないローカルアクセス」は存在しません。ネットワークの「ローカリティ」をセキュリティ回避策として使用することはありません。

2.3 SSO（シングルサインオン）を提供しますか？Active Directory（AD）をサポートしますか？

はい。SAMLプロトコルを通じてSSO（シングルサインオン）を提供しています。Active DirectoryはSAMLをサポートしており、これを使用してLokadにアクセスできます。

2.4 EZToken、Google Authenticator、またはMicrosoft Authenticatorのような二要素認証をサポートしますか？

はい。二要素認証はSAMLを介した委任認証によって実現されます。SAMLを通じて、Lokadは第一の認証要素も第二の認証要素も管理せず、このプロセスは委任されています。

2.5 OAuth2認証プロトコルをサポートしますか？

デフォルトでは、LokadはSAML認証プロトコルをサポートしています。このプロトコルは、Microsoft Office 365やGoogle Workspaceなどの主要な連携アイデンティティシステムによってサポートされています。OAuth2のサポートの課題は、OAuth2自体が実際には「認証プロトコル」ではなく、数十通りに分岐する可能性のある「認証プロトコル」を設計するための非常に包括的なガイドラインの集合であるという点にあります。

その結果、企業向けソフトウェアの領域で存在する様々なOAuth2の実装は大部分が互換性に乏しい傾向があることが見受けられます。したがって、もし契約上の要件としてOAuth2が絶対条件である場合、特定の種類のOAuth2をサポートすることが可能です。しかしながら、この取り決めは、クライアント企業が運用するOAuth2のバリアントとの互換性を確保するために専用のリソースを必要とします。

2.6 LDAP統合をサポートしますか？

はい、LDAPの上にSAMLを層状に重ねたミドルウェアブリッジを通じてサポートしています。ただし、LDAPをサポートする大多数の連携アイデンティティシステムはSAMLもサポートしているため、直接SAMLを使用することを推奨します。

2.7 二要素認証を強制しますか？

Lokadの従業員については、はい。クライアントの従業員については強く推奨しますが、最終的には強制できません（認証は通常SSOを通じて委任されるためです）。この問題は、当社ではなくクライアントのIT部門の管掌事項です。

2.8 最小限のパスワード複雑性を強制できますか？

はい、ただし限定的にです。ソフトウェアセキュリティの観点からは、最小限のパスワード複雑性を義務付けることは現在、大部分が悪い慣行と認識されています。エンドユーザーは、過度に厳格なパスワード複雑性の要求に対して予測可能な形で悪い反応を示し、結果として全体のセキュリティレベルが低下する可能性があります。さらに、そのようなパスワード要求は、セキュリティ上重要なソフトウェア（パスワード管理）の複雑性を増加させる「冗長なソフトウェア」と見なされ、結果として（全体のソリューションに）不必要なリスクをもたらすと考えています。詳しくは https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/ をご覧ください。

私たちは、従来のパスワードや戦略の代わりにSSOの使用を強く推奨します。SSOを通じて、Lokad専用のパスワードを導入する必要はありません。

2.9 定期的なパスワード変更を強制できますか？

可能ではありますが、実施していません。最小限のパスワード複雑性と同様に（Authentication 2.8参照）、定期的なパスワード変更は現在、大部分が悪いソフトウェアセキュリティの慣行と認識されています。エンドユーザーは定期的なパスワード変更に対して予測可能な形で悪い反応を示し、頻繁な変更に伴う認知的負担を軽減するために、従業員がパスワードにわずかな変更しか加えないことがあり、結果としてセキュリティが逆に低下する可能性があります。最小限のパスワード複雑性と同様に、パスワード変更はセキュリティ上重要なソフトウェア（パスワード管理）の複雑性を増加させる「冗長なソフトウェア」と見なしており、結果として（全体のソリューションに）不必要なリスクをもたらすと考えています。詳しくは https://www.sans.org/blog/time-for-password-expiration-to-die/ をご覧ください。

2.10 パスワードをハッシュ化およびソルト化しますか？

はい。パスワードハッシュ関数としてscryptを使用しています。一般的に、従来のパスワードや戦略の代わりにSSOの使用を強く推奨します。SSOを通じて、Lokad専用のパスワードを導入する必要はありません。

2.11 一定回数の認証失敗後にLokadのソリューションはCAPTCHAを有効にしますか？

はい、ただし認証の委任（SSOを介して）の場合です。CAPTCHAは、一部の攻撃ベクトルを軽減する有用な手法ですが、これらはLokadのようなサプライチェーン最適化ソリューションの範囲外に完全に置かれるべきソフトウェアコンポーネントに分類されます。さらに、企業向けソフトウェアの文脈において、特にフリーウェアの場合において、CAPTCHAの付加価値はB2Cソフトウェアほど明確ではありません。

2.12 パスワードに関する一般的なセキュリティポリシーはありますか？それを強制するためのプロセスはありますか？

はい。当社のパスワードに関する一般的なセキュリティポリシーは「パスワード不要」です。Lokad専用のパスワード導入の必要性を排除するため、SSOを強く推奨します。

2.13 ユーザー管理を一元化していますか？

はい。Lokadは、当社が運用するソリューションのための独自の集中化されたユーザー管理システムを有しており、このサブシステムはLokadによって実装され、エンジニアリングチームを含むLokadの従業員のアクセスもカバーしています。

2.14 汎用/共有のユーザーアカウントを許可しますか？

いいえ。Lokadは、従業員とユーザー（Lokadプラットフォーム上での）との間に1対1の関係を強制しています。共有ユーザーアカウントの使用は厳しく推奨していません。実際、ユーザーごとに料金を請求しない理由の一つは、クライアントが従業員間でユーザーアカウントを共有するインセンティブを与えないためです。ただし、対応する従業員が存在しないユーザーアカウントを保有することが許容される場合もあります。これは通常、クライアント側の「ロボットアップロード」サービスで、Lokadにデータをプッシュする役割を持つ場合に発生します。RBAC（Role-Based Access Control）の一環として、当社はこの単一のユースケースのために最小限の権限を提供する専用の役割（「uploader」と呼ばれる）を設けています。

2.15 セキュアなVPN接続を提供しますか？

いいえ。エンドユーザーの接続は、暗号化されたチャネル（通常はTLS）を通じて行われます。

2.16 ユーザーが複数のデバイスからログインすることを許可しますか？

はい、ただし制限付きです。一般的に、上限はユーザーあたり6台のデバイスとなっており（複数デバイスの使用に対して料金は発生しません）、各セッションは単一のIPアドレスに制限されます。ただし、潜在的な脅威や乱用に対抗するため、この制限を変更する権利はLokadに留保されています。

2.17 ソリューションには、不正と判断された場合にユーザーを強制的にロックアウトまたはログアウトさせる機能がありますか？

はい。この機能を使用するには、Lokadアカウント内で「Owner」アクセス権が必要です。

2.18 指定されたアイドル時間の後に、システムは非アクティブなユーザーを自動的にログオフしますか？

はい、ただし「アイドル状態」であることが決定的な要因ではありません。Lokadは、指定された時間が経過するとユーザーを自動的にログオフします。ユーザーは「アクティブ」であってもログオフを延期することはできず、指定された時間に達すると再認証が必要となります。

2.19 共有アカウントおよび／またはアクセス認証情報の使用は禁止されており、これらのポリシーの遵守は監視されていますか？

はい。詳細は Authentication 2.14 をご覧ください。

2.20 ユーザーIDおよびパスワードは、別々の媒体（例：電子メールおよび電話）を通じて伝達／配布されますか？

はい、ユーザー認証情報のセキュリティを最優先し、ベストプラクティスに沿った方法で伝達されるようにしています。内部的には、当社のシステムはユーザー認証のためにAzure Active Directoryを活用しており、ユーザーIDと初期パスワードが配布される際、Azure Active Directoryはセキュリティを考慮したデフォルトパターンに従います。さらに、Azure ADに対しては二要素認証を強制し、認証プロセスに追加のセキュリティ層を設けています。

外部向けには、当社のシステムに接続するクライアントの従業員に対し、シングルサインオン（SSO）と連携アイデンティティシステムの使用を強く推奨しています。これらのシステムは設計上、認証情報管理のベストプラクティスをサポートしており、認証情報が安全な方法で伝達されることを保証します。多くの場合、ユーザーIDと認証メカニズムのために別々の通信チャネルや方法が利用されます。

なお、内部ユーザーであっても外部ユーザーであっても、セキュリティの高い水準を維持することを目的とする場合、単一要素認証は推奨しません。

2.21 非アクティブな構成員のユーザーIDは、一定期間の非アクティブ状態の後に無効化および削除されますか？

はい、セキュリティを確保するために、当社はユーザーIDを積極的に管理および監視しています。Lokadの従業員に関しては、雇用最終日にすべてのアクセス権が取り消される方針となっており、元従業員の雇用終了後のアクセスは一切認められていません。

クライアント向けには、シングルサインオン（SSO）および連携アイデンティティシステムの使用を推奨しています。このアプローチによりアクセス管理が合理化され、例えばクライアントが従業員をアイデンティティシステムから削除すると同時に、Lokadへのアクセスも終了されるため、セキュリティが強化されると同時にユーザー管理の効率も向上します。

注意： ユーザーアクセスの終了に関する詳細は各クライアントとの契約書に詳述されています。Lokadは、アカウントを早期に無効化することがもたらす潜在的な業務影響を十分に認識しており、そのような事態を回避するために積極的な措置を講じています。意図しない混乱を避けるため、ユーザーアクセス終了の条件は契約書または共同で合意された手続きに明確に定められ、Lokadのセキュリティ対策がクライアントの業務ニーズに合致するようにされています。

3. 認可

3.1 ソリューションは詳細なアクセス権を提供しますか？

はい。Lokadのソリューションには、詳細なRBAC（ロールベースのアクセス制御）サブシステムが含まれており、これによりクライアントはLokadアカウント内のどの「Projects」および「Files」に誰がアクセスできるかを制御することが可能です。RBACには専用のウェブユーザーインターフェース（ダッシュボード）があり、Lokadアカウント内で「Owner」指定を受けた全ユーザーが利用できます。詳細は当社の user roles and permissions ドキュメントをご覧ください。

3.2 ソリューションは、最小特権の原則（PoLP）に従ってクライアントがアクセス設定を行えるようになっていますか？

はい。Lokadのソリューションには、PoLPを実装するために利用できる詳細なRBAC（ロールベースのアクセス制御）サブシステムが含まれています。しかし、ソリューションのDSLであるEnvisionを通じて、Lokadはこの原則において多くの企業向けソフトウェアよりも一歩進んだ機能を提供しています。

Envisionを通じて、Lokadはサプライチェーン最適化に無関係な一連のシステム特権を完全に排除しました。残された部分は簡素化されていますが、依然として大幅に構成可能です。同様に、Lokadが提供するカスタムファイルシステムも、不要なシステム特権のグループ全体を排除しています。

3.3 最小特権のアクセス権を強制しますか？

はい、ただし「最小限に受け入れ可能な」特権が何であるかは最終的にクライアントが決定します。Lokadはクライアントのスタッフに対して「Owner」指定が誰に利益をもたらすかを一方的に決定することはできません。しかし、この点に関してガイダンスを提供することは可能です。実際、Lokadのサプライチェーン科学者チームの支援を受けている「マネージド」クライアントに対しては、望ましい組織体制と対応するアクセス権を文書で明確にしています。

3.4 ソリューションには、指定されたユーザーから特定のエンティティを非表示にする機能がありますか？

はい。これはPoLP実装の一形態であり、回答 3.1、3.2 および 3.3 で取り上げられています。

3.5 データに対する分類（機密レベル）が設けられており、この分類に基づいて制御が調整されていますか？

はい。組み込み要素として、Lokadはデフォルトで、すべての管理データ（例：アカウントを持つユーザーのリストなど）をアカウントの「Owners」に限定しています。この指定は、RBAC（ロールベースのアクセス制御）の中で最も高く、特権的なものです。Lokadアカウント内のその他のすべてのデータは、ユーザー定義の機密性分類に従って区分することが可能です。このユーザー定義分類は、クライアントがアップロードした元のデータと、Lokadのプラットフォーム内で実施されたデータ変換の結果である変換後のデータの双方に適用できます。

アクセス制御および指定に関する詳細については、回答 3.1、3.2 および 3.3 をご覧ください。

3.6 ソリューションはリアルタイムでユーザー／ロール／トランザクションを認可またはブロックできますか？

はい。ただし「リアルタイム」という用語は、Lokadソリューションのような分散コンピュータシステムの文脈では明確な定義が必要です。RBAC（ロールベースアクセス制御）の更新は同期的に行われ、通常は数秒以内（一般的にはそれより短い）に有効となり、1時間や1日といった目に見える遅延は発生しません。

トランザクションの中断については、Lokadにはトランザクションデータベースが存在しないため、該当しません。とはいえ、Lokadは「プロジェクト実行」と呼ばれる長時間実行される非同期処理の中断を実施できます。中断がトリガーされると、即座（同期的）にシステムへ影響（例えばファイルの上書き等）を及ぼさないよう保証します。ただし、処理の停止自体は非同期であり、通常20秒以内に反映されます。

3.7 ソリューションは個人識別情報（PII）へのアクセスを、適切な権限レベルを持つユーザーにのみ制限していますか？

はい。ただし、ソリューションは（ソリューションへアクセスする従業員の認証識別子を除く）PIIデータを保持することを目的としていません。これはLokadとクライアントの双方に当てはまります。ソリューション内では、「オーナー」と指定された従業員のみがユーザーリストにアクセスできます。サプライチェーン最適化の目的上、LokadはPIIデータを必要とせず、また有益でもなく、その点については契約上の取り決めがなされています（Practices 1.4 & Practices 1.5 で説明）。

アクセス制御や指定に関する詳細は、3.1、3.2 および 3.3 の回答をご参照ください。

3.8 ソリューションは、個人識別情報（PII）データの検索フィルターでワイルドカード検索を禁止する機能を持っていますか？

はい。ただし、Lokadアカウント内の「オーナー」と指定されたユーザーは、アカウントにアクセスを許可された全てのユーザー（クライアントスタッフを含む）にアクセスできるため、Lokad側でこの機能を制限することはできません。クライアントは、自身のアカウントにアクセス可能なユーザーのリストを完全に監査できる必要があります。

3.9 システムにはWAF（ウェブアプリケーションファイアウォール）技術が搭載されていますか？

いいえ。WAFは、そもそも「最小権限」セキュリティ原則に反する危険な設計です。コンポーネントが「マン・イン・ザ・ミドル」として動作するために莫大な権限を与えられることで、WAF自体が攻撃者の主要な標的となり、プラットフォーム全体の攻撃対象領域が大幅に拡大します。しかし、Lokadは自社プラットフォーム上のウェブトラフィックと異常なユーザー挙動を綿密に監視しており、これらの機能はプラットフォーム自体に組み込まれているため、特権を持つ分離されたサードパーティのソフトウェアコンポーネントに委任されていません。

参照：Employees 6.6.

3.10 ネットワークにはIPS（侵入防止システム）技術が搭載されていますか？

いいえ。IPSもまた「最小権限」セキュリティ原則に違反する危険な設計であり、コンポーネントが「マン・イン・ザ・ミドル」として動作するために莫大な権限を与えられる結果、攻撃者にとって主要なターゲットとなり、プラットフォーム全体の攻撃対象領域が大幅に拡大します。Lokadプラットフォームの侵入耐性を高めるため、私たちの設計はそもそも攻撃対象領域を最小限に抑えることから始めています。事後的に「防ぐ」よりも、設計段階で侵入経路を排除する方が遥かに安全だと考えています。

参照：Employees 6.6.

3.11 サービスはDoS（サービス拒否）攻撃保護技術を利用していますか？

はい。LokadはReCaptcha、nginxのレート制限、及び認証が無効な場合の早期失敗など、独自のコンポーネントを活用しています。

3.12 本番環境への全ての管理アクセスはジャンプホストまたはバスティオン・サーバーを通じて実施されていますか？

はい。私たちは本質的に『Teleport』に類似したシステムを採用しており、これにより全アクセスの完全なトレースが可能になるとともに、従業員のアクセス権を安全に取り消す運用が実現されています。

3.13 管理アクセスの付与にあたり、信頼性のある監査証跡を残す明確な認可プロセスは存在しますか？

はい。Logging and Monitoring 5.1 および 5.11 をご参照ください。

3.14 管理アクセス権が、変更された役割や職務に沿って定期的に見直される、体系的かつ定期的なアクセス権レビューのプロセス（認可された担当者による実施）は存在しますか？

はい。管理アクセス権には2つのレベルがあります。

第一レベル: Lokadのインフラを支えるための管理権限です。これらの権限は、LokadのIT部門によって付与および監視されます。

第二レベル: 各Lokadアカウント内での管理アクセス権です。管理しているアカウントの場合は担当のサプライチェーンサイエンティストが、直接管理していないアカウントの場合はクライアント企業自身が、これらの権限を付与および監視します。

3.15 アクセス制限ポリシーは、「最小権限」原則に従い、必要かつ承認されたトラフィックのみを許可していますか？

はい。私たちは、ネットワークトラフィックを含むインフラ全体の各アクセスレベルに対して最小権限（PoLP）の原則を適用しています。アクセス制限の厳格さは利用ケースにより異なり、たとえば、特定のアクセスでは特定のIPアドレスからの認証済みユーザーのみが許可される一方、CDN（コンテンツデリバリネットワーク）のコンテンツのように、誰でもどこからでもアクセス可能な場合もあります。

参照：Authorization 3.3.

3.16 本番環境からのアウトバウンド接続は制限されていますか？

いいえ。本番環境からのアウトバウンド接続は一律に制限されていません。一部の特殊なサーバー（ロードバランサーなど）にはアウトバウンド接続の制限がありますが、大多数のサーバーは制限を受けていません。

当社の本番VMは複数の外部APIへのアクセスを必要とします。これらAPIの大部分はMicrosoft Azure上にホストされていますが、letsencrypt.orgなど例外も存在します。IPアドレスの厳格なホワイトリストを維持することは、管理の複雑さが利点を相殺するため、見送っています。アウトバウンド接続の制限は限定的なセキュリティ上の利点を提供する一方で、本番環境のセキュリティに悪影響を及ぼす可能性もあります。

3.17 顧客／クライアントがセキュリティインシデントを報告するための、24時間365日体制の連絡窓口（例：メール、ウェブフォーム、電話等）は存在しますか？

はい。セキュリティインシデントの報告を円滑にするため、security.txt標準を実装しています。

security.txtアプローチは、特定のテキストファイルをウェブサイト上に配置し、セキュリティ脆弱性の報告方法を詳細に記述する、ウェブセキュリティにおいて広く認識されたパターンです。

当社のsecurity.txtファイルは https://www.lokad.com/.well-known/security.txt に配置され、セキュリティインシデントの報告に関する最新のプロセスが記載されています。これにより、顧客、クライアント、またはセキュリティ研究者を問わず、誰でも簡単に連絡先や報告手順を確認できます。

なお、security.txtに記載されたプロセスは改訂される可能性がありますが、常に最新かつ正確な情報がそのエンドポイントに提供されます。ファイルに記載されたメール、ウェブフォーム、またはその他の連絡手段は、24時間365日体制で配置され、セキュリティ報告に迅速に対応できるようになっています。

4. データ管理

4.1 データはどこでホストされ、処理されていますか？

弊社のSaaS（サービスとしてのソフトウェア）プラットフォームは100% Microsoft Azure上にホストされており、より正確には北ヨーロッパ（ダブリン拠点）のMicrosoft Azureデータセンターに配置されています。バックアップは西ヨーロッパ（アムステルダム拠点）のMicrosoft Azureデータセンターに保存されています。大規模なデータセンター障害が発生した場合、プラットフォームをダブリンへ移行するためのコンティンジェンシープランがあり、2010年のMicrosoft Azure移行以降、このような事態は一度も発生していません。すべての顧客データはヨーロッパ内に存在し、大規模障害時においてもヨーロッパ内に留まります。

4.2 データの所有者は誰ですか？

弊社のクライアントは、Lokadにアップロードする全てのデータの唯一の所有者です。また、Lokadアカウントを通じて生成される全てのデータの所有権もクライアントに帰属します。Lokadは、クライアントが依頼したタスクに直接寄与する目的以外でクライアントデータを内部利用することはなく、クライアントのデータへのアクセスを第三者に（再）販売することも、タスク遂行に直接必要なごく限られたホスティングプロバイダー（例：クラウドコンピューティングプラットフォームからの仮想マシンレンタルによる計算処理）を除いて共有することもありません。

4.3 データベース管理は内部で行われていますか、それとも外部委託されていますか？

Lokadのデータ層管理は、Lokadのエンジニアリングチームによって行われています。前述の通り、Lokadのコアプラットフォームにはトランザクションデータベースが含まれておらず（Authorization 3.6 参照）、その代わりにイベントストアを採用しています。このイベントストアは完全にLokadによって実装・運用されています。

4.4 ソリューションはRDBMSデータベース（PostgreSQL、Oracle、MySQL）とNoSQLデータベース（Cosmos）との切り替えが可能ですか？

理論上は可能ですが、LokadソリューションはRDBMSを使用していないため、実質的な議論の余地はありません。Lokadのデータ永続化層は、イベントストアとキーバリューストアを活用したアプローチを取っており、これは企業向けソフトウェアで一般的なCRUD（作成・読み取り・更新・削除）設計とは大きく異なります。LokadがSaaSソリューションである以上、古いデータのアクセス性を保証するため、データ永続化と後方互換性については当社が全面的に責任を負っています。

4.5 ソリューションの運用に第三者は関与していますか？

はい。特に、Lokadが利用している基盤となるクラウドコンピューティングプラットフォームであるMicrosoft Azureが該当します。ソリューションの運用に関与する第三者は非常に少なく、低レベルのインフラホスティングに限定されています。Lokadは、自社ソリューションの開発、管理、運用に第三者を利用しておらず、エンジニアリングチームやテクニカルサポートチームはすべて内部に所属しています。

4.6 レイヤー（ネットワーキング、サーバー、アプリケーション）を分離していますか？

はい。ただし、ネットワークおよびサーバーの低レベル管理は、Lokadが利用している基盤となるクラウドコンピューティングプラットフォーム（Microsoft Azure）に委任されています。そのため、ネットワークおよびサーバーレイヤーの分離は主にLokadの管理範囲外となり、Lokadソリューション内ではアプリケーションレイヤーに付与される権限を厳格に制限し、DNS管理など自らのインフラ管理ができないようにしています。

4.7 データの完全削除を確実に行うプロセスはありますか？

はい。ただし、すべての手順を完了するまでに数週間かかる場合があります。このプロセスは、クライアント組織内の認可された担当者によって発行される正式な書面による削除依頼によって開始され、実際のところ、このような依頼に関する具体的な規定は、Lokadとクライアントとの契約書に明記されています。まず、本番システムからデータが削除され、その後バックアップシステムからも削除されます。後者のステージが、処理の「遅さ」をもたらす原因となっています。これは設計上の選択であり、本番システムから一度削除されたデータは、非常事態の災害復旧プロセスを除き再アクセスが不可能となります。

デフォルトでは、Lokadソリューションは全ての通常の削除操作をソフトデリート（完全削除ではない）として扱っています。この設計により、クライアント従業員による誤削除や、攻撃者による悪意のある削除といったセキュリティ上の問題を回避できます。また、意図的に遅い完全削除プロセスは、クライアント従業員になりすました攻撃者によるソーシャルエンジニアリング攻撃のリスクを軽減するためにも必要です。

4.8 ソリューションにはデータのソフトデリート機能がありますか？

はい。Lokadソリューションはイベントソーシング設計を採用しているため、ユーザーエントリやLokadのファイルシステムへの変更がすべてバージョン管理され、ソフトウェアによる削除はすべてソフトデリートとして扱われ、必要に応じて追跡および元に戻すことが可能です。

4.9 直接的なデータベースアクセスを提供していますか？

はい。Lokadソリューションの一部であるファイルシステムは、FTPSやSFTPなどのプロトコルを通じてアクセス可能です。このアクセスは、入力または出力として使用される全てのデータがこのファイルシステム内に格納されているため、非常に広範です。

しかし、Lokadにはトランザクションデータベースが存在しないため、「アクセス可能」とされる基盤のデータベースは存在しません。最も近い概念はイベントストアですが、イベントストリームへの直接アクセスは提供していません。ただし、契約上の合意により、特定の利用ケースが存在する場合、イベントストリームからの特定抽出に対応することは可能です。

4.10 ソリューションは外部データをどのように統合しますか？

ソリューションは、FTPSやSFTPなど複数のプロトコルを利用して外部データを統合できます。また、ウェブユーザーインターフェースを用いた手動でのファイルアップロードも可能です。Lokadソリューションは、合理的なタブ形式のデータであれば何でも統合でき、詳細はGo to IT Perspective on Lokad 2.15をご参照ください。

4.11 システムには、リアルタイムデータフィードからのチェンジデータキャプチャ（CDC）を処理する能力がありますか？

はい。これはクライアントとの特定の契約上の合意に基づきます。チェンジデータキャプチャはソフトウェア設計パターンであり、特定のデータ標準や転送プロトコルではなく、「リアルタイム」に求められる遅延はサブミリ秒からサブ分まで変動します。この分野の機能はサプライチェーンの観点から評価する必要があり、私たちの経験ではリアルタイムデータフィードはサプライチェーン問題においてはあまり有効ではありません。

4.12 ソリューション内の全データはエクスポート可能ですか？

はい。Lokadアカウント内のファイルシステムを通じてアクセス可能な全てのデータは、FTPSやSFTPなどのプロトコルを用いてエクスポートできます。

4.13 ソリューションはデータをエクスポートするツールを提供していますか？

はい、Lokadソリューションはサプライチェーン分析に特化したDSL（ドメイン固有言語）であるEnvisionを提供しています。EnvisionはLokadアカウント内のデータの再フォーマットに関する幅広い機能を備えています。

4.14 エクスポートされるデータのフォーマットは何ですか？

LokadプラットフォームはCSVやXLS（Microsoft Excel）をはじめとするすべての一般的な表形式フォーマットをサポートしています。また、数値、日付、区切り文字、テキストエンコーディング、ヘッダーなどのフォーマットに関する多数のオプションが用意されています。

4.15 このソリューションは、モバイルおよびバックエンドストレージにおいて個人を特定できる情報（PII）の透明なデータ暗号化（TDE）を実装していますか？

透明なデータ暗号化は、Lokadのバックエンドストレージ（データ保管時のAzureストレージ暗号化を通じて）およびLokadが発行するデバイス（BitLockerを通じて）で使用されています。Lokadは、TDEが有効になっていないデバイスにPIIを保存しません。

4.16 アプリケーション内で使用される全てのパスワードやシークレットは暗号化され、ソースコード、設定ファイル、ビルドパラメーターなどでプレーンテキスト形式でアクセスできないようになっていますか？

はい。プラットフォームレベルのすべてのシークレットはMicrosoft Azureが提供するサービスであるKey Vaultに保存されています。ユーザーパスワードは、標準的な手法に従い内部でソルトおよびScryptによってハッシュ化されています。

4.17 このソリューションには、ファイルタイプやサイズに基づいてファイルのアップロードを制限し、悪意のある内容をスキャンする機能がありますか？

はい、限定的ではありますが可能です。ファイルサイズに関しては、サプライチェーン最適化では大容量ファイルの処理が頻繁に求められます。これらのファイルサイズは、最終的に処理される履歴ビジネスデータ（例：過去の販売注文）の抽出を反映しています。この現実を踏まえ、Lokadプラットフォームは最大100GBまでのファイルサイズをサポートしています。

ファイルタイプについては、既知の拡張子と期待されるフォーマットのホワイトリストがあります。正当なユースケースがある場合、このパラメーターは調整可能です。この調整は契約書に反映されます。

悪意のある内容をスキャンする機能に関しては、Lokadにはこの機能がありません。私たちのソリューションはプラットフォーム生成コンテンツの共有を重視しており、また採用している設計により、入力ファイルが安全でなくともLokad内で生成されるファイルは安全であることが保証されています。逆に、設計上、Lokadソリューションはユーザーがアップロードしたコンテンツの共有を軽視しています。

4.18 推奨されるデータ保持期間はどのくらいですか？

LokadはSaaSであるため、適切なデータ保持期間の選択は当社の責任であり、その期間はデータの種類によって異なります。データ抽出パイプラインを通じてクライアントからLokadに送信された履歴取引データは、通常Lokadサービスの期間中保存されます。実際、履歴データはLokadサービスの枠外でも、任意の長期間保持する価値があります。一方で、プラットフォームの詳細なパフォーマンスを反映する計測データは、予期せぬ遅延のトラブルシューティングにのみ有用であり、このデータは非常に細分化されているため、通常は数週間以上保存されません。

4.19 データ構造のドキュメントは提供されていますか？

はい、「Joint Procedure Manual」の一部として提供されています。なお、Lokadは他の多くのエンタープライズソフトウェアとは異なり、リレーショナルデータベースを使用していません。その代わりに、イベントソーシングパラダイムを採用しています。ただし、クライアント企業にとって重要なデータ構造はイベントソースに存在するのではなく、Lokadプラットフォーム内のEnvisionスクリプトにより生成されたフラットファイルに存在します。これらのフラットファイルはクライアント企業の特定の要件に合わせて設計されており、そのドキュメントは「Joint Procedure Manual」に含まれています。これは典型的なLokadイニシアチブの成果物の一つです。

4.20 他の顧客のデータとのセグメンテーションはシステム設計の一部ですか？

はい。Lokadはマルチテナントアプリケーションですが、テナント、すなわちクライアントアカウント間でデータは設計段階で分離されています。このパーティショニングは、当社のバックエンド設計において最重要の要素です。この設計により、プラットフォーム内で一般的な機能をさらに開発する際に、一方のテナントのデータが他方のテナントに露出するようなプログラミングミスを防いでいます。Lokadが使用する主要な基盤ストレージであるMicrosoft AzureのBlob Storageは、このような厳格な設計段階でのパーティショニングを促進します。

4.21 開発およびテスト環境で顧客データが使用されないようにするための有効な対策は講じられていますか？

はい。デフォルトでは、ソフトウェアエンジニアリングチームは顧客データに直接アクセスできません。顧客データにアクセスせずに円滑に業務を進められるよう、広範な「モック」データ環境および「モック」データセットを開発しています。さらに、Lokadは自社のプラットフォームを内部データ解析目的（例：Microsoft Azureから取得したクラウドコンピューティングリソースの詳細な消費量の分析）で使用しています。この「ドッグフーディング」慣行により、Lokadは開発およびテスト目的で使用可能な、重要でないデータを豊富に確保しています。

しかし、診断目的のために、必要最小限（読み取り専用）の顧客データの断片にアクセスするための特別な制限付きパイプラインを構築しています。このパイプラインは、取得されるデータを厳格かつ完全に自動で最小限にすることを自動的に保証します。さらに、診断操作の終了時にデータを自動的に削除する仕組みも備えています。See 4.22

4.22 開発またはテストで顧客データの限定的使用が必要な場合、開発およびテスト環境においてデータの安全かつ完全な破棄を保証するための明確なプロセスは定義されていますか？

はい、診断目的（通常はパフォーマンステスト）のために、顧客データの例外的な利用専用の特別な（読み取り専用）データパイプラインを構築しています。このデータパイプラインは、限られた一部のソフトウェアエンジニアリングチームのみがアクセスできます。

このデータパイプラインは、対象となる診断のために取得される顧客データの断片を自動的に最小化するように設計されています。この機能により、通常はクライアントアカウント内に存在する元のデータのごく一部のみで運用することが可能になります。さらに、エンジニアリングチームが取得するデータを手作業で選別する必要もなくなります。

最後に、このデータパイプラインは診断操作の終了時に取得されたデータを自動的に削除します。

4.23 バックアップや高可用性システムを含む、顧客データのすべての物理的な保管場所は特定され文書化されていますか？

はい。すべての顧客データは、バックアップを含め、Microsoft Azureの物理的に保護されたデータセンターに保存されています。当社は顧客データをローカル（つまり、Lokadの敷地内）に保存せず、また従業員のデバイスにも保存していません。

4.24 物理サーバーの保管場所へのアクセスは、業務遂行に必要な従業員のみに限定されていますか？

はい、Lokadの顧客データはMicrosoft Azureの安全なデータセンターに保存されており、Lokad自体はその物理的な施設へアクセスできません。Microsoftのデータセンターの物理的な所在地は公開されており、Lokadが選択したデータセンターも公に文書化されています。

4.25 Primary Account Number (PAN) は、正当なビジネス目的のために絶対に必要な場合にのみ保存されますか？

LokadはクライアントのPANを受信、保存、または管理しません。

PAN（Primary Account Number）は通常、クレジットカードまたはデビットカード上の主要な番号を指します。これはカードの表面に刻印または印刷された数字の連なりであり、カードに紐付く銀行口座を一意に識別するために使用されます。

支払い処理のため、PANを管理する第三者に完全に依存しています。しかし、Lokadが受け取る取引の大部分は銀行振込で行われるため、PAN管理の問題は完全に解消されています。

当社は、銀行自体から提供される指針に従い、Lokad独自のカード用としていくつかのPANを安全に管理しています。

4.26 エンドユーザーメッセージング技術（例：メール、インスタントメッセージ、チャット）によって未暗号化のPANが送信されることはありませんか？

はい、未暗号化のPAN（Primary Account Numbers）は、メールなどの安全でないチャネルを通じて送信されることはありません。Lokadはプラットフォーム上で組み込みの安全な通信チャネルを提供しており、これは機密性の高い資料を送信するための優れた代替手段です。不安全なチャネルの使用が重大なビジネスリスクをもたらす場合には、このチャネルを推奨します。

注意: 設計上、LokadはクライアントのPANを受信、保存、または管理しないため、未暗号化のPANの転送は一切行われません。

さらに、the storage of PANsを参照してください

4.27 クラウドコンピューティングサービスプロバイダーとの契約は締結されており、その契約にはクラウドコンピューティングサービスプロバイダーの情報セキュリティに関する条項が含まれていますか？

はい、LokadはMicrosoftとの間でAzureクラウドコンピューティングサービスに関するEnterprise Agreement (EA) を締結しています。Enterprise Agreementには通常、サービスの利用に関連する各種の条件が含まれており、クラウド環境のセキュリティに関するコミットメントも含まれています。

主要なクラウドサービスプロバイダーの一つであるMicrosoft Azureは、セキュリティを非常に重視しています。Azureにはクラウド上のデータを保護するための包括的なセキュリティ機能や対策が実装されており、これらはエンタープライズ顧客との契約にも反映されています。

当社は契約の具体的な詳細を公表することはできませんが、Microsoftとの10年以上にわたる協力を経て、この契約が当社のセキュリティ要件および基準を満たしていると確信しています。

4.28 クライアントの詳細情報やデータの処理に、サブコントラクターは関与していますか？

いいえ、Lokadはクライアントの詳細情報またはデータの処理をサブコンタクトしていません。Lokadのプラットフォームに関しては、コンピューティングリソース（主に仮想マシンおよびBlobストレージ）をMicrosoft Azureから購入していますが、それ以外にクライアントデータに関与する第三者はいません。

Lokadのプロフェッショナルサービスの提供に関しては、専任のLokad社員（この場合、サプライチェーンサイエンティスト）のみがクライアントの詳細情報やデータにアクセスします。Lokadでは長期インターンシップとして数名のインターンを受け入れることがありますが（他社と比べて非常に少ないですが）、彼らは上級サプライチェーンサイエンティストの直接かつ厳格な監督下で業務を行っています。

注意: インターンも専任のサプライチェーンサイエンティストと同様の機密保持契約の対象となります。

5. ログ記録とモニタリング

5.1 アクセスログ（ユーザー、日付、最終接続日など）は提供されていますか？

はい。LokadはCSV形式のアクセスログを提供しています。現時点では、これらのログはLokadサポートスタッフにリクエストすることができます。ログの抽出結果はLokadアカウント内の「Owner」権限を持つユーザーのみがアクセスできる場所に配置されます。Lokadプラットフォームのバックエンドに既に存在する完全な監査証跡へ、専用のウェブインターフェイスを通じたより直接的なアクセス方法を導入する予定です。

5.2 ソリューション内のすべてのコンポーネントのログを一元化していますか？

はい。Lokadのイベントソーシング設計は、ログだけでなく、ソリューション内で起こるすべての状態変化も一元化しています。これらのログは他の状態変化と共に、同じイベントストアで管理される少数のイベントストリームにまとめられます。内部的には、ソリューションの状態に影響を与えないログは、影響を与えるログから分離されています。

純粋に技術的な観点から、パフォーマンスに関連する一部のログは意図的にイベントストア内に一元化されていません。これらのログには、例えば、Lokadの内部パフォーマンスプロファイリング計測装置（例：Envisionスクリプトの実行中に各関数呼び出しに費やされるミリ秒数）のような、詳細なパフォーマンス測定情報が含まれています。これらのパフォーマンスログには、「security-related」とみなされる情報は含まれていません。

5.3 アプリケーションで行われた変更や操作は記録されていますか？また、すべてのトランザクションを追跡していますか？

はい。Lokadのイベントソーシング設計により、すべてが必然的にログとして記録されます。実際、ソリューション自体が、記録されたイベントの集合の総和となっています。したがって、ログ記録はソリューションのアーキテクチャにおける基本的な側面です。このイベントソーシング設計により、状態変化を反映するログの記録漏れが防がれます。このようなイベントソーシングフレームワークでは、一般的なトランザクションデータベース（例：MySQL、Oracleなど）における通常の意味でのトランザクションは存在せず、それらは状態変化に関連するすべての情報を含むイベントに置き換えられます。

5.4 フォレンジック目的のために、各コンポーネントのログフォーマットを正規化していますか？

はい。監査およびセキュリティの観点から、「logs」は基盤となるイベントの変換結果です。イベントは技術的にはシリアライズされたオブジェクトです。ログを得るために、LokadソリューションはこれらのイベントをCSVファイルに変換およびコンパイルします。CSV抽出で使用される日付形式、数値形式、ユーザー識別子は正規化されています。

5.5 何らかのクエリプロトコルを介して第三者へログのエクスポートを提供していますか？

はい、クライアントとの契約に基づいて提供しています。

5.6 ソリューションで発生するすべての例外を追跡していますか？

はい。Lokadのイベントソーシング設計により、ソリューション内で発生するすべての例外を追跡し、初めに問題を引き起こした状況を再現することが可能です。一度特定されると、Lokadのエンジニアリングチームは観測された例外をすべて解消します。この特定目的のために専用のツールを構築しており、未解決の例外は非常に少量に抑えています。

5.7 ソリューションは、各コンポーネント/サービスの稼働状況をリアルタイムで監視する能力を有していますか？

はい。当社のサブシステムは、ヘルスチェック専用のモニタリングエンドポイントを備えるように設計されています。これらのモニタリングエンドポイントから提供される情報を継続的に統合する、Lokadのエンジニアリングチーム専用のモニタリングツールが存在します（2023年1月現在）。

前述したように、「リアルタイム」は分散システムにおいてはかなり曖昧な表現です。システムの稼働状況監視の目的では、想定される遅延は数秒から約1分程度です。

5.8 ソリューションには、サードパーティの監視ツールを統合する能力がありますか？ ソリューションは SNMP または JMX、または SNMP および JMX イベントをサードパーティの監視ソリューションに送信する能力をサポートしていますか？

はい、専用の契約合意に基づいて提供されます。

5.9 ソリューションは、予定通りに開始されなかったバッチジョブの監視や、その終了の監視が可能ですか？

はい。Lokad ソリューションは、Lokad プラットフォーム内で長時間実行されるタスクを調整するための独自の内部ジョブスケジューラ（「Runflow」と呼ばれる）を備えています。通常は Envision スクリプトの実行に使用されます。このスケジューラは、ウェブユーザーインターフェースを通じて、任意のジョブシーケンスのスケジュールと実行時間枠を指定するように設定できます。

5.10 ソリューションは、事前に警告を発する能力を持っていますか？ また、エラーを相関し分析した上で、事前に対策を講じる能力はありますか？

はい。ソリューションのジョブスケジューラである Runflow は、実行中のシーケンスが遅延していることをクライアントまたは Lokad に通知できます。この警告はシーケンス完了前に送信されることがあります。Lokad ソリューションは、Envision（独自 DSL）を通して状況を分析し自己診断する広範な機能を提供し、事前対策を講じることができます。ただし、Lokad プラットフォームがこの機能を提供する一方で、実際のロジックの実装についてはエンジニアが Envision を用いて行う必要があり、サプライチェーンの状況により「エラー」と見なされる条件は異なります。

5.11 ソリューションは、監査データの保持機能を持っていますか？ ユーザー活動の監査のために、データがアーカイブされ、MIS データベースにパージ（削除）されていますか？

はい。イベントソーシング設計により、Lokad ソリューションは広範な監査トレイルを保持しています。これは、通常、イベントストアの代わりにトランザクションデータベースを利用するより一般的な設計で得られるものよりもはるかに大きいものです。Lokad ソリューションは、管理情報システム（MIS）を別個のサブシステムとして分離していません。実際、イベントストリーム自体が監査トレイルとなります。より一般的には、Lokad はクライアントとのサービス期間中、運用データを保持します。契約の終了時には（交渉された契約条件に依存しますが）、クライアントデータは削除されますが、バックアップシステム内での最終削除は契約終了後数ヶ月かかることがあります。

5.12 システムには自己監視機能（技術的および機能的）を統合していますか？

はい、Lokad プラットフォームは複数の自己監視機能を様々なレベルで統合しています。

クラウドホスティングされたプラットフォームは、Lokad のソフトウェアエンジニアリングチームによって監視されています。Lokad プラットフォームはマルチテナントであるため、この監視は主に「システム」視点で実施され、プラットフォームの機能（パフォーマンスプロファイルを含む）が標準に沿っていることが保証されます。この目的のために、独自のインストゥルメンテーションレイヤーを設計しました。「機能的」監視は、対象のサプライチェーンの具体性に依存するため、通常はクライアント固有となり、この監視は契約に基づき Lokad が提供するサプライチェーン科学者（エンジニア）のチームによって提供されます。

Lokad のサプライチェーン科学者は通常、特定のクライアントアカウントの分野（例：航空宇宙）に特化しています。彼らは、Lokad アカウントを使用してオーダーメイドの監視インストゥルメンテーションを構築します。この監視には、Lokad が提供する数値が技術的な意味だけでなく、クライアントのビジネスの観点からも正確であることを確認することが含まれます。

5.13 異常や侵害の兆候を検知するために、ログはタイムリーかつ体系的にレビューおよび分析されていますか？

はい。Lokad プラットフォームの継続的な活動のレビューは、我々の日常業務の一部です。プラットフォームの設計はこのプロセスを容易にしています。

また、ログ記録と監視 5.2も参照してください。

5.14 ログ管理システムは、他のシステムの管理に関与していない人々によって運用されていますか（すなわち、職務の分離）？

はい。ログおよびプラットフォームの全般的な活動の監視はサプライチェーン科学者によって行われ、インフラの一般的な管理は IT 部門の特定の従業員によって行われます。

5.15 アプリケーションレベルの脆弱性スキャンは定期的かつ体系的に実施されていますか？

はい、ただしそのようなスキャンは当社のセキュリティプロセスのごく一部です。従業員 6.6も参照ください。

5.16 効果的なファイアウォールルールの定期的な見直しのための明確なプロセスは定義されていますか？

はい、当社の生産マシンは、限られた数のポートのみを開放するなど、非常に厳格なルールが適用されています（Microsoft Azure を通じて設定）。インフラの設定はスクリプト化され、その進化は通常のコードレビュープロセスに従っています。この実践は、定期レビューを容易にするだけでなく、そもそも手動でルールを見直す必要性を軽減します。

5.17 ネットワークは IDS（侵入検知システム）技術を備えていますか？

いいえ。IDS は本質的に危険な設計です。なぜなら、それは「最小特権」のセキュリティ原則に反するため、あるコンポーネントが「マン・イン・ザ・ミドル」として動作するために膨大な権限を与えられることになるからです。これにより、IDS 自体が攻撃者にとって主要な標的となり、プラットフォームの攻撃面が大幅に拡大されます。しかし、Lokad はウェブトラフィックや自社プラットフォーム上の異常なユーザー行動を綿密に監視しています。ただし、これらの機能はプラットフォーム自体の一部であり、特権を持つ独立したサードパーティのソフトウェアコンポーネントに委任されているわけではありません。

また、従業員 6.6も参照してください。

6. 従業員

6.1 従業員は秘密保持契約（NDA）を締結していますか？

はい、すべての Lokad 従業員は雇用契約に NDA 条項が含まれています。

6.2 従業員はセキュリティ意識およびセキュリティトレーニングを受けていますか？

はい、機密データに接する、または機密データに接するエンジニアリングシステムに関与する Lokad 従業員には、セキュリティ意識およびセキュリティトレーニングが提供されています。この点に関する詳細は、サプライチェーンのためのサイバーセキュリティの講義をご覧ください。この講義は、機密クライアントデータを取り扱うサプライチェーン科学者向けです。

6.3 Lokad において、誰がクライアントデータにアクセスできますか？

クライアントは、Lokad アカウントにアクセスできるユーザーのリストを明示的に定義します。これらのユーザーは、Lokad アカウント内で設定されたアクセス権に応じて、クライアントのデータの各種クラスにアクセスできる場合があります。権限管理専用のウェブアプリケーション（「Hub」と呼ばれる）も存在します。

Lokad 側では、各クライアントアカウントごとにアクセス可能な従業員の簡略なリストが存在します。まず第一に、このリストには、サプライチェーン最適化ソリューションを実装・維持するために Lokad が提供するサプライチェーン科学者（エンジニア）が含まれます。これらのサプライチェーン科学者は、日々クライアントのデータにアクセスすることが求められます。社内では、クライアントアカウントへのアクセスは、そのアカウントに明示的に割り当てられたサプライチェーン科学者にのみ限定されています。つまり、サプライチェーン科学者 A は、クライアントとの取り決めがない限り、クライアントアカウント B にアクセスできません。

第二に、このリストには当社プラットフォームのシステム管理を担当するエンジニアリングチームも含まれます。一般的に、クライアントデータへの直接アクセスは稀であり、クライアント自身やサポートするサプライチェーン科学者から報告された状況の調査に限定されています。Lokad は、クラウドコンピューティングプラットフォームを除き、クライアントデータへのアクセスを第三者と共有しません。

6.4 従業員のワークステーションはどのように保護されていますか？

ソフトウェアエンジニアリングチームを除き、Lokad 従業員は会社支給のデバイス上で管理者権限なしで操作します。すべてのワークステーションは、ハードウェアの紛失、盗難、または第三者への預け入れ（例：修理）の際に生じるデータ窃盗を防ぐため、フルディスク暗号化が施されています。

当社従業員が使用するワークステーションには、クライアントのデータは含まれていません。必要に応じて、例えばプレゼンテーション用に数枚の Excel シートをダウンロードすることはありますが、当社の方針として、クライアントデータはすべて厳重にクラウド上で保護されます。

6.5 従業員のスマートフォンはどのように保護されていますか？

Lokad 従業員には会社支給のスマートフォンはありません。カレンダーのリマインダーなどの重要でないデータは個人の（会社支給でない）デバイスにプッシュされることがありますが、スマートフォンもワークステーション同様、クライアントのデータは含まれていません。

6.6 ウイルス対策ソフトは使用していますか？

はい、当社のワークステーションには Microsoft Defender が搭載されており、Microsoft Windows 10 以降の設定に従っています。Microsoft Defender 以外のウイルス対策ソフトは使用していませんが、この種のツールはセキュリティの観点から見れば不利益をもたらすことが多いと考えています。逸話的な例として、2020 年の SolarWinds ハックは、史上最大級のコンピュータセキュリティ災害の一つとされ、本来セキュリティ向上を目的とするソフトウェアが原因となりました。より一般的に、セキュリティ目的のほぼすべてのソフトウェア製品は非常に高いシステム権限を要求します。その結果、これらの製品自体が攻撃のベクトルとなります。我々のコンピュータセキュリティに対する見解は「少ないほど良い」というものであり、技術の非常に複雑な要素を当社のアプリケーション環境に追加することは、ほぼ確実に安全性を高めるのではなく、むしろ低下させると考えています。

6.7 ソフトウェア開発者は、脅威評価手法、安全なコーディング基準、有名なセキュリティチェックリストおよびフレームワークの使用について定期的なトレーニングを受けていますか？

はい。しかし、有名なチェックリストのほとんどは、設計上不安全なアーキテクチャを反映しているに過ぎません。可能な限り、設計段階でセキュリティ上の落とし穴の原因を排除することを優先します。従業員 6.2も参照してください。

6.8 Lokad の下請け/外部労働力とのすべての契約に秘密保持契約（NDA）は含まれていますか？ この NDA は顧客情報を対象としていますか？

はい、いずれも当てはまりますが、現時点で Lokad は下請けや外部労働力に依存していません。Lokad のソフトウェアエンジニアリングおよびサプライチェーン科学者のチームは、Lokad の直接の常用雇用および監督下にある人員で完全に賄われています。

ただし、もし Lokad が下請けと契約する必要があると判断した場合、その下請けは常用従業員と同じ知的財産権および NDA 条項の対象となります。これらの契約には、Lokad のクライアントに関する情報に関する条項が含まれます。

6.9 Lokad の外部労働力全員に、内部情報およびセキュリティのオリエンテーション（および継続的な関連トレーニング）は提供されていますか？

現時点で Lokad は下請けや外部労働力に依存しておらず、Lokad のソフトウェアエンジニアリングおよびサプライチェーン科学者のチームは、Lokad の直接の常用雇用および監督下にある人員で完全に賄われています。

ただし、もし Lokad が外部労働力との契約を必要と判断した場合、これは必須要件となります。すべての下請け/外部労働者は、常用従業員と同じセキュリティプロセスおよびトレーニング要件の対象となります。

前述の通り、現時点で Lokad は外部労働力に依存していないため、そのようなトレーニングは行われていません。

また、従業員 6.8も参照してください。

6.10 Lokad のサービス提供に参加するすべての外部労働者（下請け、コンサルタントなど）を提供する企業との契約には、外部労働者に対する身元調査が義務付けられていますか？ これらの身元調査は、情報へのアクセスレベルおよび従業員の役割の重大性に応じたものですか？

現時点で Lokad は下請けや外部労働力に依存しておらず、Lokad のソフトウェアエンジニアリングおよびサプライチェーン科学者のチームは、Lokad の直接の常用雇用および監督下にある人員で完全に賄われています。

ただし、もし Lokad が外部労働力との契約を必要と判断した場合、これは必須要件となります。すべての下請け/外部労働者は、常用従業員と同じセキュリティプロセス、身元調査およびトレーニング要件の対象となります。

注意: 歴史的に見ても、サイバー諜報などの大規模で最悪のインシデントの多くは、非常に優れた経歴を持つ人々によって引き起こされています。このことを含む複数の理由から、Lokad は外部労働力に依存することを控え、直接かつ無期限の雇用契約を強く好んでいます。

6.11 雇用終了時に管理者アカウントは自動的に無効化または削除されますか？

はい。すべての Lokad 従業員は、フェデレーテッドアイデンティティプロバイダー（Microsoft Azure Active Directory）を通じてアクセス権を取得しています。雇用終了時（該当する場合）は、このアクセス権が取り消され、それに伴いすべての関連管理権限が自動的に無効化されます。

注意: 多くの Lokad 従業員には、職務遂行に必要ないため、管理者権限は付与されません。

6.12 機密データ、財務データ、銀行データ、クレジットカードデータなどにアクセスできるすべてのスタッフに対して、犯罪歴の身元調査を実施していますか？

はい、身元調査は実施される業務の要件に厳密に従って実施されます。

なお、Lokad は社内でクレジットカードデータを管理しておらず、これはサードパーティによって管理されています。したがって、Lokad のスタッフはクライアントのクレジットカードデータにアクセスできません。

6.13 作業が行われる敷地に、許可されていない人員がアクセスできないようにするため、Lokad はどのような予防策を講じていますか？

建物レベルでは、Lokad は 24 時間 7 日体制で第三者による監視と、現地に配置された警備員があるオフィスビル内で運用されています。

オフィスレベルでは、Lokad の敷地には独自の安全なアクセス制御が設けられており、建物自体のアクセス制御とは独立しています。この最終層は、同じ建物内の他社の従業員が Lokad のオフィスにアクセスするのを防ぎます。

注意: 特別な訪問者（クライアント、候補者など）は、Lokad のスタッフによって直接迎えられ、入館が許可される必要があります。

6.14 施設への訪問者は許可されていますか？

If “facility” means “クライアントデータが保存および処理される場所”, then no. クライアントデータはMicrosoft Azureのデータセンターに保存されています。これらのデータセンターは一般公開されておらず - Lokad自身もアクセスできません。

しかし、Lokadは時折、企業本社を訪れる来客を歓迎しています。私たちのオフィスは一般公開されていませんが、クライアントの訪問、面接待ちの応募者など、例外的な状況が発生することがあります。そのような訪問は事前に計画され、訪問中は常にLokadのスタッフが同伴します。

6.15 紙のデータ記録（およびデータを含む取り外し可能な電子メディア）は、夜間に安全な耐火キャビネットに保管されていますか？

Lokadは紙のデータ記録も取り外し可能な電子メディアも使用していません。物理的な記録の保管がないため、耐火キャビネットは必要ありません。

たとえ文書を印刷することがあったとしても（実際、Lokadはごく稀に文書を印刷します）、プリンターの隣にシュレッダーが設置されています。Lokadの基本方針は機密文書を印刷しないことですが、万が一印刷が必要となった場合には、使用後すぐに印刷された文書をシュレッダーで裁断するのが当社の基本方針です。

6.16 クリアデスクポリシーは実施されていますか？もしそうであれば、その範囲はどの程度ですか？

はい、Lokadは確固たるクリアデスクポリシーを実施しています。このポリシーは、当社のデジタル環境を通じて「by design」により強制されています。

法的に印刷を義務付けられているごく少数の文書や、必要に応じて印刷される一部の文書（例：展示会用のポスター。ただし、これも通常は外部委託されます）を除き、Lokadの作業環境は完全にデジタルです。

このように、業務終了時には、Lokadの従業員は「片付けるべきもの」が何もありません。従業員のコンピューターセッションがロックされると（これは厳格に施行されるポリシーです）、その机は事実上、片付いた状態になります。

6.17 ファックスはどこに届き、誰がアクセスできるのでしょうか？

Lokadは物理的なものも仮想的なものも含め、ファックス機を一度も所有したことがありません。当社がこの技術に対する立場を変更するための有力な活用事例は認識していません。

6.18 解雇時に、（コンピュータ、携帯電話、アクセスカード、トークン、スマートカード、鍵などの）構成資産の返却を確認するプロセスはありますか？

はい、当社にはそのプロセスが整備されているだけでなく、この取り組みを支援し事務的ミスを最小限に抑えるためのIT資産管理ソフトウェアも導入しています。

しかし、Lokadのセキュリティは、構成資産が速やかに返却されることに依存しないよう意図的に設計されています。Lokadは、いかに規律正しく訓練された従業員であっても、構成資産が紛失または盗難に遭う可能性が十分にあると考えています。実際にはこのような事態はごく稀ですが、エンジニアリングの観点からは逆の前提で設計しています。このため、構成資産はリモートで無効化することが可能です。さらに、適用可能な場合は全ディスク暗号化を実施しています。

より一般的に、当社の作業環境はワークステーション、ノートブック、または携帯電話上にクライアントデータの永続的な保管を必要としないよう設計されています。この設計により、万が一他の予防策が失敗した場合でも、構成資産の重要性が大幅に軽減されます。

6.19 人事（HR）ポリシーおよび／または手順は、経営陣によって承認され、関係者に伝達されていますか？また、それらを維持・見直す担当者は任命されていますか？

はい、当社の人事ポリシーおよび手順は上級管理職によって正式に承認されています。私たちは明確なコミュニケーションを重視しており、そのためこれらのポリシーと手順は、完全な理解と遵守を保証するためにすべての関係者に十分に周知されています。

さらに、ポリシーと手順の継続的な保守、更新、定期的な見直しを担当するオーナーを任命しています。これにより、当社の運用が最新かつ関連性があり、業界標準および組織の目標と一致していることが保証されます。

6.20 組織に関連する個人が使用する、会社所有ではない個人所有（BYOD）のモバイルデバイスでクライアントデータにアクセスしているものはありますか？

いいえ、Lokadは個人所有（BYOD）のモバイルデバイスによるクライアントデータへのアクセスを許可していません。当社は従業員に高品質な会社所有のハードウェアを提供しており、個人デバイスの使用を不要としています。この方針は、従業員が低品質な会社ハードウェアへの不満から自身のデバイスを使用するという一般的な状況に対処するものです。

さらに、当社の運用プロトコルは、会社所有のデバイス上でもクライアントデータが永続的に保存されないように設計されています。すべてのデータ処理はクラウドベースのプラットフォーム上で行われ、従業員のデバイス上ではクライアントデータ（もしアクセスされた場合でも）は一時的かつ最小限のセグメントのみで扱われ、最大限のセキュリティが確保されます。

備考