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

Lokadはサプライチェーンの専門企業です。技術的な創意工夫によって、より優れたサプライチェーンの意思決定を実現することを第一の目的としています。同時に、重要な財務データを日々扱うため、プラットフォームのセキュリティにも最優先で取り組んでいます。セキュリティを後付けの事務手続きに任せず、明確な原則に基づき、計画的かつ先回りして対処します。この姿勢は、ソフトウェアの設計、人材の採用・配置、研修における具体的な選択に表れています。

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

セキュリティの原則

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

設計による安全性

設計は、ソフトウェアセキュリティで特に過小評価されている要素の一つです。ここでいう設計とは、開発の根幹をなす選択を指します。こうした選択は、とりわけ攻撃対象となり得る範囲に大きく影響します。Lokadは設計によって、セキュリティ問題を種類ごと排除してきました。例えば、SQLデータベースではなく、処理を実行しない単純なBLOBストレージを使っています。攻撃対象のSQLデータベース自体が存在しないため、SQLインジェクションなどの問題がなくなります。また、永続化層はすべて追記専用です。バージョン管理のように既存データを上書きせず変更を追加するので、すべての変更を追跡し、取り消せます。これにより、攻撃者を含め誰であっても、データを削除したりLokadのログを改ざんしたりすることが非常に難しくなります。

ほとんどのエンタープライズソフトウェアベンダーは、根本的な設計上の選択が製品を左右することを十分に認めていません。そのため、セキュリティ問題が絶えません。例えば、ほぼ必須となる設定・カスタマイズ機能をPythonやJavaScriptのような汎用言語で実現すると、セキュリティ問題は必然的に生じます。汎用プログラミング言語を完全に安全にすることは、ほぼ不可能だからです。Lokadは意図的に、すべての設定・カスタマイズをドメイン特化型言語（DSL）のEnvisionで行う設計を選びました。Envisionは、OSやファイルシステムなどのサブシステムに直接アクセスする機能を設計上持たないため、はるかに安全です。

文化による安全性

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

第一に、Lokadはマーケティングで伝える内容を、可能な限り事業の実態に合わせています。好意を得られるか批判を受けるかにかかわらず、この方針を守ります。これは、非現実的で、ときには空想的ですらある主張を公表する多くのエンタープライズソフトウェアベンダーとは対照的です²。実態と対外的な説明の食い違いに気づいた鋭い従業員は、やがて関心を失います。その無関心が油断を生み、セキュリティ問題につながります。そうした従業員が退職し、食い違いに気づかない「信じ込みやすい人」だけが残ることも珍しくありません。信じ込みやすさも無関心も、セキュリティには望ましくない性質です。

第二に、技術面・非技術面を問わず、セキュリティを含む事業全体について好奇心と健全な懐疑心を育てています。従業員が慣行の見直しや改善に参加できるよう訓練し、働きかけることで、柔軟に対応できる組織になります。常に新たな攻撃方法を考える相手に先手を打つには、この柔軟性が役立ちます。サプライチェーンでも、必ずしも犯罪ではない対抗的な行動は日常的に見られるため、この姿勢は有用です³。

研修による安全性

全従業員がサイバー脅威とその軽減方法を理解できるよう、積極的に研修を行っています。設計や文化とは異なり、研修は主に上から教える活動です。現場からの発想にも役割はありますが、研修だけで多くのセキュリティリスクに対処するには本質的な限界があります。ある行為をしないよう教えても、誰も絶対にしないとは想定できません⁴。そのため、より厳格に対応します。機器を侵害されるおそれのある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が事業を停止した場合には、顧客が自動的にコードへのアクセス権と、サービスを自社で再構築するための制約の少ないライセンスを取得できるようにしています。

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

はい。顧客ごとに、その組織内の連絡窓口を決めています。Lokad側では主担当と代替担当の少なくとも2名、通常はサプライチェーンサイエンティスト2名が、緊急の連絡を担います。実際に直面する危機の大半は、ソフトウェアのセキュリティではなく、顧客から提供されたデータをもとに発見するサプライチェーン上の緊急事態です。セキュリティ事故が発生した場合も、同じ連絡経路で速やかに顧客へ知らせます。

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

Lokadに顧客のITシステムへのアクセス権を与えず、顧客側からLokadへデータを送信し、Lokadから取得する構成を強く推奨します。Lokadで起きたセキュリティ事故が顧客のシステムへ波及する可能性を減らすためです。SSO（シングルサインオン）も強く推奨します。Lokad用のパスワードが何らかの方法で盗まれ、それを使って顧客の別のシステムが侵害されるという経路をなくせます。

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

ゼロトラストの設計により、その時点で権限を持つ人だけがデータにアクセスできます。ネットワーク内にいるだけで特別な立場や権限を得ることはありません（認証2.1を参照）。ネットワークの安全性を監視するとともに、まず攻撃対象となり得る範囲を可能な限り小さくしています。

主要なネットワークは二つあります。一つはソリューションを稼働させるMicrosoft Azureです。そのネットワークの安全性は全面的にMicrosoftに委ねています。基本的なロードバランサ以外に、Azureの「高度な」ネットワーク機能は利用していません。

もう一つはパリ本社のローカルネットワークで、Lokadのエンジニアリングチームが安全性を管理しています。ここには、本番環境を構成するコンポーネントやシステムを一切置いていません。

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

はい。Lokadは多くのエンタープライズソフトウェアベンダーに比べ、外部コンポーネントへの依存が非常に少ない構成です。主要なものはMicrosoftの.NETやFacebookのReactなど、広く利用され信頼性のあるオープンソースプロジェクトに限られるため、利用条件の社内監査も比較的容易です。

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

Lokadは当初から妥当なセキュリティ設計と運用を採用してきたため、大小を問わず、変更がセキュリティに影響することは仮定上もまれです。これまでに本当に重要だった変更は3件あります。2010年のMicrosoft Azureへの移行、2012年の顧客・従業員向けの委任認証導入、そして2022年の社内認証のGoogle AuthenticationからMicrosoft Azure ADへの移行です。

いずれもソフトウェア開発チームが数か月前から準備しました。変更前に資料を用意して研修を行い、全従業員が対応できるようにしました。移行後は、通常の方針に従って従来のアクセス経路を廃止しました。

2023年1月現在、大きな変更の予定はありません。必要になった場合も、ほぼ確実に同様の手順を取ります。

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

契約には、顧客と合意した終了手続きを詳しく定めています。最後の段階は顧客データの完全な削除です。手続き自体にもリスクがあるため、顧客ごとに協議し、多少異なる内容を定めることがあります。例えば、攻撃者が顧客になりすまし、早期解約を起こして業務を妨害するおそれがあります。そのため、ソーシャルエンジニアリングで容易に悪用されない手続きを共同で決め、契約上の義務とします。通常は書面での確認と、所定の待機期間を設けます。

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

通常は、プラットフォーム運用の月額定額料金と、顧客を担当するサプライチェーンサイエンティスト、すなわちLokadのエンジニアによるサービスの月額定額料金を請求します。詳細は交渉のうえ契約に記載します。この二つですべてを含む料金体系となり、保守、ライセンス、外部の導入業者やコンサルタントなどの追加料金はありません。サービスの範囲と規模には、契約で合意した上限があります。

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

はい。ご要望に応じて、基本となる契約書のひな型を提供できます。ただし、サプライチェーンの取り組みの規模、対象国、想定するサービス範囲によって条件は大きく変わります。可能であれば、まず導入を検討する企業と話し合い、取り組みの内容を明確にしてから、適切な契約の枠組みを作ります。

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

はい。対面・リモートの両方に対応し、詳細は契約時に取り決めます。また、詳しい技術文書と一連のサプライチェーン講義を公開しています。講義では、Lokadの技術とサプライチェーンに対する考え方を説明しています。

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

はい。Lokadは該当する基準に従って運用しています。ただし、提供するのはサプライチェーンの予測的最適化であり、業務を直接制御するものではありません。通常は資源配分の最適化を通じて間接的に作用するため、この場合、ISO規格は該当しません。

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

詳しくは取り組み1.12を参照してください。

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

はい。そのため、設計段階から安全性を考慮しています。脅威を種類ごと排除すれば、全体の脅威評価も管理しやすくなります。ソフトウェアのサプライチェーン攻撃も評価対象です。外部コンポーネントへの依存は一つ増えるたびに攻撃対象を広げるため、その数を最小限に抑えています。

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

はい。事故にはさまざまな種類があり、よくあるものの一つが顧客企業自身への侵害です。ランサムウェアの被害に遭い、結果としてLokad上のデータだけが利用可能なまま残ることもあります。認証情報が盗まれ、Lokadアカウントへのアクセスに使われる場合もあります。対応手順は顧客と共同で定め、Lokadが管理するアカウントでは通常、担当のサプライチェーンサイエンティストが監督します。

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

はい。通常は年に一度に限らず、年間を通じて定期的に見直します。ソフトウェア業界での重大な侵害などが、見直しのきっかけになることもよくあります。

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

はい。ただし、Lokadは基本的にモノリシックなプラットフォームです。Microsoft AzureのBlob StorageやLinux VMなど、少数の基盤要素以外の「支援機能」には依存していません。

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

はい。システムプロセスは、必要なアクセス権だけを持つ専用アカウントで実行します。デーモンにはsystemdサービスを使い、常に可能な限り少ない権限で稼働させています。

SQLデータベースは使っていませんが、定期実行やイベントを契機に実行する処理のアクセス権は、ロールに基づいて決めています。これらはシステムプロセスではなく、ユーザーランドの処理です。

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

はい。経営陣が承認した正式なリスクガバナンス計画があります。

この計画では、エンタープライズリスクマネジメント（ERM）プログラムの要件と指針を定め、組織全体のリスクを体系的かつ一貫した方法で特定、評価、管理、監視する仕組みを設けています。

計画は定期的に見直し、組織の目標やリスク環境の変化に合わせて更新します。また、継続的な監督と支援を確保するため、ERMプログラムの実施状況と効果を経営陣と関係者に定期報告しています。

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

はい。経営陣が承認した包括的な物理的セキュリティプログラムがあります。すべての関係者に十分に周知し、その理解と遵守を確保しています。

また、プログラムを有効で状況に即したものに保つため、維持、更新、定期的な見直しを担う責任者を任命しています。各チームや部門と連携して新たな物理的セキュリティの課題に対処し、適切な実務慣行と組織の目標に沿うようにしています。

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

はい。物理的・環境的リスクの評価は、システムの設置場所を決めるうえで欠かせません。当社のシステムはMicrosoft Azureのデータセンターにあり、Microsoftの厳格な施設選定・評価プロセスを利用しています。Microsoft Azureは、設置前に物理的・環境的リスクを含む潜在的なリスクを包括的に評価します。その選定では、自然災害の可能性、アクセスのしやすさ、インフラの安定性なども分析されます。

Azureのデータセンターを利用することで、こうした評価が包括的に実施され、当社のシステムに最高水準の物理的セキュリティと環境リスクへの耐性が確保されていると確信しています。

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

はい。ただし、倫理をトップダウンで押し付けるべきではないと考えています。そのような方法は、必ず本来の目的に反する結果を生みます。

有名な例がEnronです。同社には、尊重、誠実さ、コミュニケーション、卓越性を掲げた倫理規範がありました。しかし、2001年に発覚した不祥事では、これらの原則に明らかに反する大規模な会計不正が判明しました。文書で公言された倫理と、実際の商慣行や企業文化は完全に乖離していたのです。

このためLokadは、従業員が顧客を真剣に気にかけられる機会を持てるよう努めています。「私たちは正しいことをしているか」は、当社のモットーの一つです。コンプライアンスと倫理は、特定のプログラムではなく、適切な企業文化から生まれるものと考えています。

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

はい。Lokadは内部監査、リスク管理、コンプライアンスの独立した専任部門を置くほどの規模ではありませんが、これらを重視しています。各分野の専門知識を持つ担当者を任命し、実務と監督を担わせています。

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

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

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

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

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

2. 認証

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

はい。顧客データや重要な機能にアクセスするには、事前の認証が必要です。ただし、仕組み上、認証なしで利用できなければならない箇所もあります。例えば、ログインページそのものにアクセスする際には認証を求めません。そのページで認証を行うからです。

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

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

はい。適切な認証、認可、通信経路の暗号化をすべて必須としています。これは顧客のユーザーにも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が必須であれば、特定の実装に対応することは可能です。ただし、顧客が使用する実装との互換性を確保するため、専用のリソースが必要になります。

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 定期的なパスワード変更を強制できますか？

可能ですが、実施していません。複雑さの最低要件と同様に（認証 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のようなサプライチェーン最適化ソリューションの外部に置くべき機能です。また、エンタープライズソフトウェアにおける効果は、B2Cソフトウェア、とりわけ無料ソフトウェアの場合ほど明確ではありません。

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

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

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

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

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

いいえ。Lokadでは、従業員とプラットフォーム上のユーザーを1対1で対応させています。アカウントの共有は強く避けるよう求めています。ユーザー数に応じて課金しない理由の一つも、顧客が従業員間でアカウントを共有する動機をなくすことです。ただし、特定の従業員に対応しないアカウントが認められる場合もあります。通常は、Lokadへデータを送信する顧客側の自動アップロードサービスです。この用途に必要な最小限の権限だけを与える専用ロール「uploader」を、RBAC（ロールベースのアクセス制御）の一部として設けています。

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

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

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

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

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

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

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

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

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

はい。認証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 ソリューションは詳細なアクセス権を提供しますか？

はい。ロールベースのアクセス制御（RBAC）により、顧客はアカウント内の「Projects」と「Files」に誰がアクセスできるかを細かく設定できます。専用のウェブ画面は「Owner」ロールを持つ全ユーザーが利用できます。詳しくはユーザーロールと権限の文書を参照してください。

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

はい。細かなRBAC設定によって最小権限の原則を適用できます。さらに、DSLであるEnvisionにより、ほとんどのエンタープライズソフトウェアよりはるかに徹底してこの原則を実現しています。

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

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

はい。ただし、どの権限が最低限必要かを最終的に決めるのは顧客です。顧客のどの従業員に「Owner」ロールを与えるかを、Lokadが一方的に決めることはできませんが、助言はできます。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）へのアクセスを、適切な権限レベルを持つユーザーにのみ制限していますか？

はい。ただし、Lokadや顧客の従業員がログインするための識別情報を除き、個人識別情報を保持することは想定していません。ユーザー一覧を閲覧できるのは「Owner」ロールの利用者だけです。サプライチェーン最適化に個人識別情報は不要で、有用でもありません。この点は契約でも定めています（取り組み1.4、取り組み1.5を参照）。

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

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

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

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

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

参照：従業員6.6。

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

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

参照：従業員6.6。

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

はい。ReCaptcha、nginxによるリクエスト頻度の制限に加え、無効な認証を伴うリクエストを早い段階で拒否する仕組みなど、独自のコンポーネントを使っています。

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

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

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

はい。ログ記録とモニタリング 5.1および5.11を参照してください。

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

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

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

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

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

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

認可 3.3も参照してください。

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

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

当社の本番VMは複数の外部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のデータ層は自社のエンジニアリングチームが管理しています。前述のとおり、コアプラットフォームにはトランザクションデータベースがなく（認可 3.6参照）、代わりにイベントストアを採用しています。このイベントストアは、実装から運用までLokadがすべて担当しています。

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

理論上は可能ですが、LokadはRDBMSを使っていないため、実際にはこの切り替えは問題になりません。データ永続化層にはイベントストアとキーバリューストアを採用しており、エンタープライズソフトウェアに多いCRUD（作成・読み取り・更新・削除）設計とは大きく異なります。SaaSを提供する当社が、データの永続化と、今後も古いデータにアクセスできる互換性について全面的に責任を負います。

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

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

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

はい。ただし、ネットワークとサーバーの低レベルの管理は、基盤となるクラウドコンピューティングプラットフォームMicrosoft Azureに委任しています。そのため、この二つのレイヤーの分離は主にLokadの管理範囲外です。Lokad側ではアプリケーションレイヤーの権限を厳しく制限し、自らのインフラを管理できないようにしています。例えば、DNS管理への書き込み権限はありません。

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

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

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

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

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

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

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

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

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

FTPSやSFTPなどのプロトコルを使って外部データを取り込めます。ウェブ画面から手動でファイルをアップロードすることも可能です。適切な表形式に整理されたデータであれば取り込めます。詳しくはITの観点から見た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）を適用していますか？

はい。バックエンドではAzureストレージの保存時の暗号化を、Lokadが支給する端末ではBitLockerを使用し、透過的にデータを暗号化しています。TDEが有効になっていない端末にPIIを保存することはありません。

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

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

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

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

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

悪意のある内容をスキャンする機能はありません。Lokadは、プラットフォーム内で生成したコンテンツの共有を重視しています。採用している設計により、入力ファイルが安全でなくても、Lokad内で生成するファイルの安全性を確保しています。一方、ユーザーがアップロードしたコンテンツの共有は、設計上、中心的な用途としていません。

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

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

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

はい。「共同手順書」の一部として提供しています。Lokadは、多くのエンタープライズソフトウェアと異なり、リレーショナルデータベースではなくイベントソーシングを採用しています。ただし、顧客にとって重要なデータ構造は、イベントストアではなく、プラットフォーム内でEnvisionスクリプトが生成するフラットファイルにあります。これらのファイルは顧客ごとの要件に合わせて設計されており、その仕様を共同手順書に記載します。この手順書は、通常のLokadプロジェクトで提供する成果物の一つです。

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

はい。Lokadはマルチテナントアプリケーションですが、テナント、つまり顧客アカウント間のデータ分離を設計自体に組み込んでいます。この分離はバックエンド設計の最重要事項です。一般的な機能を追加開発する際にも、一方のテナントのデータが他方に漏れるようなプログラミングミスを防ぎます。主要な基盤ストレージであるMicrosoft AzureのBlob Storageも、こうした厳格な分離を設計に組み込むうえで役立っています。

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

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

ただし、診断に必要な最小限の顧客データだけを読み取り専用で取得する、特別な制限付きパイプラインを設けています。取得するデータを厳格かつ完全に自動で最小化し、診断が終わると自動削除します。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の転送は一切行われません。

PANの保管も参照してください。

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

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

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

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

4.28 顧客の詳細情報やデータの処理を外部委託していますか？

いいえ。顧客の詳細情報やデータの処理は外部委託していません。プラットフォーム用の計算資源、主に仮想マシンとBlobストレージをMicrosoft Azureから購入していますが、それ以外に顧客データを扱う第三者はいません。

専門サービスでは、フルタイム勤務のLokad従業員、具体的にはサプライチェーンサイエンティストだけが顧客の詳細情報やデータにアクセスします。長期インターンを少人数受け入れることもありますが、その数はほとんどの他社よりはるかに少なく、上級サプライチェーンサイエンティストが直接かつ厳格に監督します。

注：インターンにも、フルタイム勤務のサプライチェーンサイエンティストと同じ秘密保持契約が適用されます。

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

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

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

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

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

技術上の理由から、一部の性能ログは意図的にイベントストアに集約していません。例えば、内部の性能計測機構が記録する、Envisionスクリプトの各関数呼び出しにかかったミリ秒数などの詳細な測定値です。こうした性能ログには、セキュリティに関係する情報は含まれていません。

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

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

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

はい。監査・セキュリティ用のログは、基になるイベントを変換して作成します。イベントは技術的にはシリアライズされたオブジェクトです。これらを変換し、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アカウント内に顧客専用の監視の仕組みを構築し、提供する数値が技術的に正しいだけでなく、顧客の事業の観点からも適切であるかを確認します。

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 従業員はセキュリティ意識およびセキュリティトレーニングを受けていますか？

はい。機密データを扱う従業員や、そのデータを扱うシステムの開発に携わる従業員に、セキュリティ意識の向上と実務のための研修を提供しています。詳しくは、機密性の高い顧客データを扱うサプライチェーンサイエンティスト向けの講義、サプライチェーンのためのサイバーセキュリティをご覧ください。

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

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

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の直接の無期雇用と監督下にある従業員です。

外部委託が必要になった場合は、委託先にも無期雇用の従業員と同じ知的財産権・NDAの条件を適用します。これらにはLokadの顧客情報に関する条項も含まれます。

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

執筆時点でLokadは外部委託先や外部人材を利用していません。ソフトウェアエンジニアリングとサプライチェーンサイエンティストの両チームは、全員がLokadの直接の無期雇用と監督下にある従業員です。

外部人材の利用が必要になれば、これを必須要件とします。すべての外部委託先・外部人材に、無期雇用の従業員と同じセキュリティ手順と研修要件を適用します。

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

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

6.10 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 施設への訪問者は許可されていますか？

「施設」が顧客データを保存・処理する場所を指すなら、いいえ。顧客データはMicrosoft Azureのデータセンターに保存されており、一般の立ち入りは認められていません。Lokad自身も立ち入れません。

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

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

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

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

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

はい。クリアデスクポリシーを徹底しています。業務環境をデジタル化することで、机に書類を残さない状態を仕組み自体で実現しています。

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

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

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

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

6.18 退職時に、コンピューター、携帯電話、入館カード、トークン、スマートカード、鍵などの貸与品が返却されたかを確認する手順はありますか？

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

ただし、Lokadのセキュリティは、貸与品が速やかに返却されることに依存しない設計です。どれほど規律正しく研修を受けた従業員でも、紛失や盗難は起こり得ると考えています。実際にはまれでも、設計上は起こることを前提にします。そのため、貸与品は遠隔で無効化でき、適用できるものにはフルディスク暗号化も施しています。

また、業務環境は、ワークステーション、ノートパソコン、携帯電話に顧客データを恒久保存する必要がないよう設計しています。ほかの予防策が機能しなかった場合にも、機器に伴うリスクを大幅に抑えられます。

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

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

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

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

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

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

備考