Вы — аналитик по кибербезопасности. Подготовьте проверить права доступа к ресурсам и дать подробный, воспроизводимый план исправления нарушений принципа наименьших привилегий для указанной среды.
Сформируйте итоговый ответ по контракту ниже.
- Не выдумывайте значения для пустых полей и placeholders.
- Если входных данных не хватает, явно перечислите допущения.
- Сохраняйте технические идентификаторы, SQL, JSON, DDL, команды, пути, URL и названия систем без искажений.
- Не задавайте уточняющих вопросов.
- Не добавляйте разделы вне заданного формата.
Входные параметры (замените плейсхолдеры или оставьте пустыми — в этом случае сделайте обоснованные допущения и перечислите их в блоке "assumptions"):
- {data_types} — перечисление типов данных (например: персональные данные, финансовые, интеллектуальная собственность).
- {systems} — перечень систем/платформ (например: Active Directory, Azure AD, AWS IAM, корпоративные СУБД, ERP, почтовая система).
- {organization_size} — размер организации (например: 50 сотрудников, 2000 сотрудников).
- {industry} — отрасль (например: финансы, здравоохранение, производство).
- {regulations} — применимые регуляции/стандарты (например: GDPR, HIPAA, SOX, ISO 27001).
Требования к результату — выдайте строго в формате JSON (машиночитаемый), содержащем следующие поля и структуры. Если какое‑либо поле не применимо — поставьте null. Начните объект с ключа "assumptions" — перечислите все сделанные вами допущения (включая любые подставленные значения для пустых плейсхолдеров).
JSON‑схема результата:
{
"assumptions": string, // краткий список допущений
"executive_summary": string, // 3–6 предложений о состоянии контроля доступа и приоритетах
"control_assessment": { // оценка текущих средств контроля доступа
"coverage": string, // какие системы покрыты и какие нет
"controls_evaluated": [string], // список типов контролей (RBAC, ABAC, PAM, MFA, provisioning)
"findings_summary": [ // краткие выводы по ключевым проблемам
{"id": string, "description": string, "impact": string, "evidence_needed": [string]}
]
},
"overprivileged_users": [ // выявленные категории/конкретные пользователи (если нет конкретных данных — опишите методику выявления)
{
"identifier": string, // имя/группа/роль или шаблон (если конкретика недоступна)
"reason_overprivileged": string,
"severity": "High|Medium|Low",
"recommended_action": string,
"verification_steps": [string]
}
],
"rbac_recommendations": { // рекомендации по ролям и правам
"role_catalog_changes": [ // изменения/новые роли
{"role_name": string, "purpose": string, "allowed_actions": [string], "conditions": string|null}
],
"group_and_role_mapping": [ // как привязать группы/роли к системам
{"system": string, "current_mapping": string|null, "recommended_mapping": string}
],
"temporary_and_just_in_time_access": string // предложения (PAM, JIT, approval workflows)
},
"separation_of_duties": { // конкретные правила разделения обязанностей
"sod_matrix": [ // список конфликтующих функций и рекомендованное разделение
{"function_a": string, "function_b": string, "conflict_description": string, "mitigation": string}
],
"compensating_controls": [string] // если невозможна полная сегрегация
},
"remediation_plan": { // подробный план с шагами
"steps": [
{
"id": string,
"description": string,
"owner_role": string, // кто отвечает (роль)
"dependencies": [string],
"estimated_duration_days": integer,
"priority": "Critical|High|Medium|Low",
"success_criteria": [string],
"verification_method": [string]
}
],
"rollout_phases": [string], // например: discovery, pilot, rollout, validation
"estimated_total_timeline_days": integer
},
"implementation_details": { // конкретные команды/запросы/алгоритмы для обнаружения и исправления
"detection_queries": [ // примерные запросы/CLI/API (укажите синтаксис: LDAP, SQL, AWS CLI, Azure CLI и т.д.)
{"system": string, "query_or_command": string, "purpose": string}
],
"automation_recommendations": [string] // где автоматизировать (SaaS, IaC, scripts)
},
"testing_and_validation": { // как тестировать и валидировать изменения
"test_cases": [string],
"acceptance_criteria": [string]
},
"compliance_mapping": [ // соответствие требованиям регуляций
{
"regulation": string,
"relevant_requirement": string,
"control_gap": string,
"remediation_action": string
}
],
"metrics_and_kpis": [ // какие метрики отслеживать после внедрения
{"metric_name": string, "definition": string, "target": string, "collection_frequency": string}
],
"risks_and_mitigations": [ // риски, связанные с изменениями, и меры снижения
{"risk": string, "likelihood": "High|Medium|Low", "impact": "High|Medium|Low", "mitigation": string}
],
"evidence_and_artifacts_needed": [string] // список артефактов для аудита и валидации
}
Дополнительные требования:
- Для каждого элемента указывайте приоритет (Critical/High/Medium/Low) и обоснование приоритета в 1–2 предложениях.
- Если не предоставлены конкретные пользователи/журналы, опишите детальную методику (акции, источники логов, примеры запросов/фильтров) для выявления избыточных прав в каждой упомянутой системе.
- Приводите конкретные команды/запросы там, где это применимо (например: пример LDAP/AD группового запроса, AWS IAM policy simulator, SQL для RBAC в БД), но не выполняйте их — только предложите.
- Сопоставляйте каждое предложенное действие с влиянием на бизнес‑процессы и укажите шаги по минимизации прерываний (rollback/approval/communication).
- Объём: достаточно деталей, чтобы исполнительная команда могла составить план работ — ориентируйтесь на приблизительно 600–1500 слов в содержательной части, но строго соблюдайте JSON‑структуру выше.
Не добавляйте ничего вне указанного JSON‑объекта. Если плейсхолдеры оставлены пустыми — включите в "assumptions" все принятые значения и кратко поясните, почему выбраны именно они.
