"""安全问卷 · 答案库种子补充 — DLP 与数据保护 15 条双语标准问答. Data-only seed for ``auditor_answer_library_entries``, extending the 55 entries seeded by migration 381. Customers increasingly open with "what DLP do you run?" and the library had **no** entry containing the string "DLP" at all — the term is not searchable (``list_entries`` matches question/answer text in both languages, not tags), so the question came back to a human every time. Content is grounded in the company's actual stack as confirmed by IT: endpoint side 飞连 (Feilian) zero-trust + endpoint control, Jamf Pro (macOS) and Microsoft Intune (Windows); document side Google Workspace (Docs/Drive) and 飞书 (Lark) Docs, both licensed with their data-loss- prevention capabilities; rules configured by the security team with alerting on external sharing and download/export; and a data classification scheme that drives differentiated protection policies. One entry deliberately states the SCOPE BOUNDARY: DLP as asked about in questionnaires is a corporate-endpoint/office-collaboration control, and it is not what protects the product/production environment (that is least privilege, approved and time-bound production access, PrivateLink, encryption, per-person audit trails, T+0 revocation). Answering the literal question without that boundary is how a questionnaire ends up promising endpoint DLP over customer data in production. Freshness: entries whose every claim is either IT-confirmed or already asserted by the 381 seed are stamped ``last_reviewed_at = NOW()`` (fresh). Entries that extend past that line — BYOD, peripheral/USB and print control, e-mail security, generative-AI usage — are seeded with ``last_reviewed_at`` NULL so the freshness job marks them ``review_interval_elapsed`` and the UI shows 待复核 until an owner has read and confirmed the wording. A questionnaire answer nobody has confirmed should look unconfirmed, not merely exist. Idempotent: an entry is skipped when a row with the same ``question_zh`` already exists (the library has no natural unique key; exact question text is the seed identity). Seeded rows carry ``created_by_person_id`` NULL; owners are expected to adopt/curate them in the UI afterwards. Self-contained (no app imports) per the migration chain-guard rule. Revision ID: 528 Revises: 527 """ from __future__ import annotations import json import uuid import sqlalchemy as sa from alembic import op revision = "528" down_revision = "527" branch_labels = None depends_on = None TABLE = "auditor_answer_library_entries" # ── Seed content ───────────────────────────────────────────────────── # ``needs_review`` = seed it as 待复核 (last_reviewed_at NULL) because the # claim goes beyond what IT confirmed or what migration 381 already says. SEED: list[dict] = [ # ═══ 数据防泄漏 data_loss_prevention ═══ { "category": "data_loss_prevention", "tags": ["dlp", "overview", "endpoint", "saas"], "question_zh": "贵公司是否部署数据防泄漏(DLP)方案?覆盖哪些场景?", "question_en": "Do you have a data loss prevention (DLP) capability, and what does it cover?", "answer_zh": "是。数据防泄漏(DLP)能力沿两条主线建设:①终端侧——公司终端全部纳入统一管理,飞连(Feilian)负责零信任接入与终端安全管控,macOS 经 Jamf Pro、Windows 经 Microsoft Intune 下发安全基线与合规策略,策略命中时实时告警至信息安全团队;②协同与文档侧——办公文档使用 Google Workspace(Docs/Drive)与飞书(Lark)Docs,两者均已订阅其数据防泄漏功能,由信息安全团队配置检测规则,对外部共享、下载导出等敏感操作检测并告警。两条主线之上叠加数据分类分级,不同密级的数据触发强度不同的保护策略。", "answer_en": "Yes. Our data loss prevention (DLP) capability runs on two tracks. (1) Endpoints: every corporate device is centrally managed — Feilian provides zero-trust access and endpoint security control, while Jamf Pro (macOS) and Microsoft Intune (Windows) push security baselines and compliance policies, with real-time alerts to the security team when a policy fires. (2) Collaboration and documents: office documents live in Google Workspace (Docs/Drive) and Feishu (Lark) Docs, both licensed with their data-loss-prevention capabilities, where the security team configures detection rules that flag and alert on sensitive operations such as external sharing and download/export. Both tracks are driven by our data classification scheme, so more sensitive data triggers stronger protection policies.", }, { "category": "data_loss_prevention", "tags": ["dlp", "endpoint", "mdm", "feilian"], "question_zh": "终端侧的数据防泄漏具体有哪些管控手段?", "question_en": "What DLP controls are enforced on endpoints?", "answer_zh": "终端须先纳管、通过安全检查后才能接入公司网络与业务系统:飞连(Feilian)提供零信任接入与终端安全状态检查,不合规终端不予放行;macOS 由 Jamf Pro、Windows 由 Microsoft Intune 统一下发安全基线与合规策略(含加密、补丁、防病毒与外设/本地存储策略),并集中监测合规状态。设备与使用人在资产台账中绑定;终端上的违规行为按预置规则实时告警至信息安全团队,离职或设备回收时执行标准化擦除与重置。", "answer_en": "A device must be enrolled and pass posture checks before it can reach the corporate network or business systems: Feilian provides zero-trust access with endpoint posture verification and blocks non-compliant devices, while Jamf Pro (macOS) and Microsoft Intune (Windows) push and centrally monitor security baselines and compliance policies (encryption, patching, anti-malware, peripheral and local-storage policies). Devices are bound to their holders in the asset register; policy violations on endpoints raise real-time alerts to the security team, and devices are wiped and reset through a standard procedure on offboarding or recovery.", }, { "category": "data_loss_prevention", "tags": ["dlp", "google-workspace", "lark", "sharing"], "question_zh": "文档与协同平台(Google Docs、飞书 Docs)的数据防泄漏如何实现?", "question_en": "How is DLP implemented in your document and collaboration platforms (Google Docs, Feishu/Lark Docs)?", "answer_zh": "公司文档统一承载在 Google Workspace(Docs/Drive)与飞书(Lark)Docs,两个平台均已购买数据防泄漏功能,并由信息安全团队按数据分类分级配置检测规则。规则覆盖文档的对外共享(公开链接、外部协作者)与下载、导出等敏感操作:命中时按密级执行相应策略并实时告警,由信息安全团队跟进研判与处置。文档权限随人事异动联动调整,离职时文档归属按标准流程移交接收人。", "answer_en": "Company documents are consolidated in Google Workspace (Docs/Drive) and Feishu (Lark) Docs; DLP is licensed on both platforms, with detection rules configured by the security team according to our data classification. Rules cover external sharing of documents (public links, external collaborators) and sensitive operations such as download and export: on a match, the policy for that sensitivity level applies and a real-time alert goes to the security team for triage and handling. Document permissions follow HR-driven joiner/mover/leaver changes, and document ownership is transferred to a named recipient through the standard offboarding process.", }, { "category": "data_loss_prevention", "tags": ["dlp", "classification", "policy"], "question_zh": "是否对数据进行分类分级?不同级别的保护策略有何差异?", "question_en": "Do you classify data, and do protection policies differ by classification level?", "answer_zh": "是。我们按敏感度对数据进行分类分级,并以级别作为数据防泄漏(DLP)防护策略的输入:级别越高,共享与外发限制越严格(如限制公开链接与外部协作者、限制下载导出)、告警级别与响应时效要求越高、访问授权所需的审批层级越高。分类分级同时决定介质处置与备份保护的强度,并纳入 ISO/IEC 27001 与 ISO/IEC 27701 体系的年度评审。", "answer_en": "Yes. Data is classified by sensitivity, and the classification is an input to the DLP protection policy: higher levels mean tighter sharing and egress restrictions (for example public links and external collaborators restricted, download/export limited), higher alert severity with shorter response targets, and more approval layers for access. Classification also sets the rigour of media disposal and backup protection, and is reviewed annually under our ISO/IEC 27001 and ISO/IEC 27701 management systems.", }, { "category": "data_loss_prevention", "tags": ["dlp", "alerting", "incident"], "question_zh": "DLP 规则触发告警后如何处置?", "question_en": "What happens after a DLP rule raises an alert?", "answer_zh": "告警实时进入信息安全团队的处理队列:先研判是否为误报;确认为真实风险的,联系当事人及其主管核实业务背景,必要时立即撤销共享、回收权限或隔离终端,并按安全事件响应流程升级处理。处置过程全程留痕、可追溯,事件闭环包含根因分析与规则调优以防止同类问题再发;违反信息安全制度的行为按公司制度惩处。", "answer_en": "Alerts enter the security team's queue in real time: the team first rules out false positives, then — for a genuine risk — contacts the individual and their manager to confirm the business context and, where warranted, immediately revokes the share, removes the entitlement or isolates the endpoint, escalating through the security-incident response process. Every step is logged and traceable; closure includes root-cause analysis and rule tuning to prevent recurrence, and breaches of the security policy are sanctioned under company disciplinary rules.", }, { "category": "data_loss_prevention", "tags": ["dlp", "scope", "production", "customer-data"], "question_zh": "数据防泄漏方案是否覆盖你们的产品/生产环境?", "question_en": "Does your DLP programme cover your product / production environment?", "answer_zh": "需要区分两类场景。数据防泄漏(DLP)体系针对的是企业办公场景——员工终端与办公协同平台上处理的公司数据。产品与生产环境不依赖终端 DLP,而是由另一组控制措施保护:最小权限与按需授权、生产访问经审批且高危权限设有效期到期回收、生产数据库经私有链路访问不暴露公网、传输与静态加密、操作可追溯到个人的审计日志,以及离职当日(T+0)自动回收。客户数据保存在生产环境中,不通过员工终端流转;确需访问时须经审批、留痕,并纳入周期性权限复核。", "answer_en": "These are two distinct scopes. Our DLP programme addresses the corporate office environment — company data handled on employee endpoints and in collaboration platforms. The product/production environment does not rely on endpoint DLP; it is protected by a different control set: least privilege and need-based authorization, approved production access with expiry on high-risk grants, production databases reachable only over private links with no public exposure, encryption in transit and at rest, audit logs attributing every operation to an individual, and automated same-day (T+0) revocation on termination. Customer data stays in the production environment rather than flowing through employee endpoints; where access is genuinely required it is approved, logged and covered by periodic access reviews.", }, { "category": "data_loss_prevention", "tags": ["dlp", "exfiltration", "monitoring"], "question_zh": "是否能发现异常的批量下载、导出或外发行为?", "question_en": "Can you detect anomalous bulk download, export or data-egress activity?", "answer_zh": "可以,通过三层信号叠加:①文档平台的数据防泄漏(DLP)策略对下载、导出与对外共享等敏感操作进行检测,命中即告警;②办公网络边缘部署上网行为管理系统,办公网内及经 VPN/零信任接入的访问行为可记录、可回溯;③账号侧由监控系统探测异常登录与异常访问行为并告警。三者结合用于发现异常的批量取数或外发行为,发现后按安全事件响应流程跟进至闭环。", "answer_en": "Yes, through three layers of signal: (1) DLP policies in our document platforms detect sensitive operations such as download, export and external sharing and alert on a match; (2) internet-behaviour management at the office-network edge records and preserves activity on the LAN and over VPN/zero-trust access; and (3) account-level monitoring flags anomalous sign-ins and access patterns. Together these surface abnormal bulk extraction or egress, which is then followed through the security-incident response process to closure.", }, { "category": "data_loss_prevention", "tags": ["dlp", "byod", "managed-device"], "needs_review": True, "question_zh": "员工能否使用个人设备访问公司数据?", "question_en": "May employees access company data from personal devices?", "answer_zh": "以受管终端为原则:终端须纳入 MDM 管理(macOS Jamf Pro / Windows Microsoft Intune),并通过飞连零信任接入的终端安全检查后方可访问业务系统;未经 IT 与信息安全评估审批的设备不得接入公司网络。确有例外需求的须经审批,且同样受文档平台的共享、下载导出 DLP 策略与告警覆盖。", "answer_en": "Managed devices are the rule: an endpoint must be MDM-enrolled (Jamf Pro for macOS, Microsoft Intune for Windows) and pass the Feilian zero-trust posture check before it can reach business systems, and devices not assessed and approved by IT/security may not join the corporate network. Genuine exceptions require approval and remain subject to the same document-platform sharing and download/export DLP policies and alerting.", }, # ═══ 账号生命周期 identity_lifecycle ═══ { "category": "identity_lifecycle", "tags": ["leaver", "dlp", "handover"], "question_zh": "如何防止离职员工带走公司数据?", "question_en": "How do you prevent departing employees from taking company data?", "answer_zh": "离职当日(T+0)自动回收全部账号与权限:平台角色撤销、Google 账号挂起、飞书账号冻结、下游 SaaS 经自动化连接器停用;文档与协同资料按标准流程移交指定接收人,设备执行回收、擦除与重置。离职窗口期内的共享与导出行为同样受文档平台的数据防泄漏策略与告警覆盖;内部平台内置离职者操作护栏防止误恢复,并有每日对账兜底,确保无残留访问。", "answer_en": "All accounts and entitlements are revoked automatically on the last working day (T+0): platform roles removed, Google accounts suspended, Feishu frozen and downstream SaaS deactivated via connectors. Documents and collaboration content are handed over to a named recipient through the standard process, and devices are recovered, wiped and reset. Sharing and export activity during the notice period stays covered by document-platform DLP rules and alerting, while built-in leaver guards prevent accidental re-provisioning and daily reconciliation ensures no residual access.", }, # ═══ 访问控制 access_control ═══ { "category": "access_control", "tags": ["customer-data", "production-access"], "question_zh": "内部人员是否可以访问客户数据?如何管控?", "question_en": "Can your staff access customer data, and how is that controlled?", "answer_zh": "默认不可访问。生产环境访问遵循最小权限,按业务需要申请、经审批后授予;高危权限设有效期,到期自动提醒续期或回收,超期未决升级为合规事件跟踪。所有生产操作可追溯到个人并留存审计日志;相关权限纳入每半年的全员访问自证与信息安全团队发起的访问认证复核,保留/回收决定闭环执行并留存完整记录。", "answer_en": "Not by default. Production access follows least privilege — requested on business need and granted after approval; high-risk grants carry expiry dates with automatic renewal/revocation reminders, and overdue reviews escalate as tracked compliance incidents. Every production operation is attributable to an individual and retained in audit logs, and the relevant entitlements are covered by semi-annual company-wide access self-attestation and security-run access certifications, with keep/revoke decisions executed to closure and fully recorded.", }, # ═══ 供应链 supply_chain ═══ { "category": "supply_chain", "tags": ["shadow-it", "saas-governance"], "question_zh": "如何发现和治理未经审批的 SaaS 使用(影子 IT)?", "question_en": "How do you discover and govern unapproved SaaS usage (shadow IT)?", "answer_zh": "任何软件或服务的引入均须经 IT 与信息安全评估审批后方可使用。内部 IT 平台维护第三方系统/服务清单与软件坐席台账(采购、账号、成本与使用情况),并与人事数据对账核实账号归属与离职回收;办公网络边缘的上网行为管理与账号侧监控用于发现未经审批的服务使用,发现后按准入与供应商安全评估流程补充评估,或要求停用并迁移数据。", "answer_en": "Any software or service must pass IT and security assessment and approval before use. Our internal IT platform maintains the third-party system/service inventory and a software-seat register (procurement, accounts, cost and usage), reconciled against HR data to verify ownership and leaver revocation. Internet-behaviour management at the network edge plus account-level monitoring surface unapproved usage, which is then either brought through the admission and vendor-security-assessment process or discontinued with its data migrated.", }, # ═══ 应用安全 application_security ═══ { "category": "application_security", "tags": ["source-code", "ip-protection"], "question_zh": "源代码与知识产权如何保护?", "question_en": "How is source code and intellectual property protected?", "answer_zh": "源代码集中托管在受管的代码平台(GitHub 组织),经统一身份认证接入;仓库权限按最小权限与业务需要授予,并纳入周期性权限复核。平台成员与人事数据对账,离职当日回收组织成员资格与访问令牌。代码库中不存放明文密钥(生产凭据统一存放于 AWS SSM Parameter Store,部署时注入),变更须经代码评审与 CI 门禁通过后方可合入,全过程可追溯。", "answer_en": "Source code is hosted centrally in a managed platform (our GitHub organization) behind unified authentication; repository permissions are granted on least-privilege/business-need and included in periodic access reviews. Platform membership is reconciled against HR data, and organization membership and access tokens are revoked on the leaver's last day. No plaintext secrets are kept in repositories (production credentials live in AWS SSM Parameter Store and are injected at deploy time), and changes merge only after code review and CI gates, with the whole history traceable.", }, # ═══ 终端安全 endpoint_security ═══ { "category": "endpoint_security", "tags": ["usb", "peripherals", "printing"], "needs_review": True, "question_zh": "是否管控 USB 存储、外设与打印等本地外发通道?", "question_en": "Do you control local egress channels such as USB storage, peripherals and printing?", "answer_zh": "终端纳管后由 MDM 按安全基线下发外设与本地存储的管控策略(macOS 经 Jamf Pro、Windows 经 Microsoft Intune),违规使用按规则告警至信息安全团队;打印与移动介质的使用遵循数据分类分级要求,介质处置须按制度执行彻底删除或销毁。具体策略强度按数据密级与岗位差异化配置,可按需在保密前提下提供当前策略说明。", "answer_en": "Enrolled endpoints receive peripheral and local-storage policies from the security baseline via MDM (Jamf Pro for macOS, Microsoft Intune for Windows), and violations alert the security team. Printing and removable media follow data-classification requirements, and media disposal must irreversibly erase or destroy the content per policy. Policy strength is configured by sensitivity level and role; a statement of the current policy is available on request under NDA.", }, # ═══ 邮件安全 email_security ═══ { "category": "email_security", "tags": ["phishing", "google-workspace"], "needs_review": True, "question_zh": "邮件安全与防钓鱼有哪些措施?", "question_en": "What e-mail security and anti-phishing measures are in place?", "answer_zh": "企业邮箱基于 Google Workspace,启用其反垃圾、反钓鱼与恶意附件/链接防护能力,并对邮箱账号强制多因素认证;员工安全意识培训覆盖钓鱼识别与上报,可疑邮件按事件上报流程提交信息安全团队研判。账号侧的异常登录由监控系统探测告警,确认失陷时立即挂起账号、终止会话并重置凭据,按安全事件响应流程闭环。", "answer_en": "Corporate mail runs on Google Workspace with its anti-spam, anti-phishing and malicious attachment/link protections enabled and MFA enforced on mailboxes; security-awareness training covers phishing recognition and reporting, and suspicious messages are escalated to the security team through the incident-reporting process. Anomalous sign-ins are detected by monitoring, and on a confirmed compromise the account is suspended, sessions terminated and credentials reset, closed out through the security-incident response process.", }, # ═══ AI 治理 ai_governance ═══ { "category": "ai_governance", "tags": ["genai", "llm", "data-classification"], "needs_review": True, "question_zh": "员工使用生成式 AI(大模型)工具时,公司数据如何保护?", "question_en": "How is company data protected when employees use generative-AI tools?", "answer_zh": "AI 工具与模型服务的引入和使用纳入统一准入:须经 IT 与信息安全评估审批,账号与 API 密钥在内部 IT 平台建立台账,归属、有效期与用量集中可见并监控。可提交的数据以数据分类分级为准,超出许可级别的数据不得提交至未经审批的公共 AI 服务;文档平台的数据防泄漏策略与告警同样适用于向外部服务的共享与导出行为,违规按安全事件流程处置。", "answer_en": "Adoption and use of AI tools and model services go through the same admission process: IT and security assessment and approval, with accounts and API keys inventoried in our internal IT platform where ownership, validity and consumption are centrally visible and monitored. What may be submitted is governed by data classification — data above the permitted level must not be sent to unapproved public AI services — and document-platform DLP rules and alerting apply equally to sharing or export toward external services, with violations handled through the security-incident process.", }, ] def upgrade() -> None: bind = op.get_bind() for e in SEED: exists = bind.execute( sa.text(f"SELECT 1 FROM {TABLE} WHERE question_zh = :q LIMIT 1"), {"q": e["question_zh"]}, ).scalar() if exists: continue # NULL last_reviewed_at ⇒ the freshness job marks the entry # ``review_interval_elapsed`` and the UI shows 待复核: an answer # whose wording nobody has confirmed should look unconfirmed. reviewed = "NULL" if e.get("needs_review") else "NOW()" bind.execute( sa.text( f""" INSERT INTO {TABLE} (id, category, question_zh, question_en, answer_zh, answer_en, tags, owner_person_id, status, usage_count, last_reviewed_at, review_interval_months, source_doc_ids, created_by_person_id, created_at, updated_at) VALUES (:id, :category, :question_zh, :question_en, :answer_zh, :answer_en, :tags, NULL, 'active', 0, {reviewed}, 12, NULL, NULL, NOW(), NOW()) """ ), { "id": str(uuid.uuid4()), "category": e["category"], "question_zh": e["question_zh"], "question_en": e["question_en"], "answer_zh": e["answer_zh"], "answer_en": e["answer_en"], "tags": json.dumps(e.get("tags") or [], ensure_ascii=False), }, ) def downgrade() -> None: # Remove only rows that are still recognisably the seed (same question, # never adopted by a person) — user-curated entries survive. bind = op.get_bind() for e in SEED: bind.execute( sa.text( f""" DELETE FROM {TABLE} WHERE question_zh = :q AND created_by_person_id IS NULL AND owner_person_id IS NULL """ ), {"q": e["question_zh"]}, )