[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-postroenie-sistem-biometricheskoy-verifikatsii-arkhitektura-indoneziya":3},{"article":4,"author":56},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":35,"related_articles":36},"db000000-0000-0000-0000-000000000013","a0000000-0000-0000-0000-000000000013","Построение систем биометрической верификации: архитектурные паттерны для новых требований Индонезии","postroenie-sistem-biometricheskoy-verifikatsii-arkhitektura-indoneziya","Глубокое техническое руководство по архитектуре систем биометрической верификации, соответствующих Регламенту KOMDIGI № 7\u002F2026. Компоненты системы, соответствие UU PDP, масштабируемость для 270+ млн населения и паттерны реализации на Rust.","## Обзор архитектуры системы: краткий ответ\n\nСовместимая система биометрической верификации для мандата на SIM-карты в Индонезии требует четырёх основных компонентов: **биометрический захват** (камера + SDK), **обработка живости** (PAD на устройстве или серверная), **сопоставление личности** (верификация 1:1 с базой IKD) и **безопасное хранение** (зашифрованные шаблоны с журналом аудита). Система должна обслуживать население свыше **270 миллионов человек**, обрабатывать верификации за **менее чем 3 секунды** и соответствовать как **Регламенту KOMDIGI № 7\u002F2026**, так и требованиям **UU PDP** по защите данных.\n\nЭта статья предоставляет детальный архитектурный чертёж для построения такой системы, включая проектирование компонентов, потоки данных, меры безопасности и паттерны реализации на Rust.\n\n## Основные компоненты\n\n### 1. Подсистема биометрического захвата\n\nПодсистема захвата отвечает за получение качественного изображения лица пользователя. Качество напрямую влияет на точность последующих этапов — плохо освещённое, размытое изображение приведёт к отказу верификации даже для легитимного пользователя.\n\n**Требования:**\n\n- Минимальное разрешение изображения: **640x480 пикселей** (VGA) для области лица\n- Детекция лица: необходимо определить лицо в кадре и обрезать до стандартизированного размера\n- Оценка качества: оценка освещения, угла позы, перекрытий и размытия перед продолжением\n- Формат изображения: **JPEG** с качеством 80%+ или **PNG** для захвата без потерь\n- Метаданные: временная метка захвата (ISO 8601), идентификатор устройства, GPS-координаты (с согласия пользователя), параметры камеры\n\n**Пороги качества (соответствие ISO\u002FIEC 19794-5):**\n\n| Параметр | Допустимый диапазон |\n|----------|---------------------|\n| Угол рыскания | -15° до +15° |\n| Угол тангажа | -10° до +10° |\n| Угол крена | -8° до +8° |\n| Расстояние между глазами | ≥ 90 пикселей |\n| Освещение | 100-250 люкс на лице |\n| Размытие (дисперсия Лапласиана) | > 100 |\n| Доля площади лица | > 20% кадра |\n\n### 2. Подсистема обработки живости\n\nПодсистема живости определяет, получен ли захваченный биометрический образец от живого человека. Для мандата Индонезии она должна соответствовать стандартам **ISO\u002FIEC 30107-3 Уровень 2**.\n\n**Архитектурное решение: Edge vs Сервер**\n\nДля индонезийского рынка рекомендуется **гибридный подход**:\n\n- **На устройстве (edge):** запуск облегчённой модели живости (MobileFaceNet или аналог, \u003C30 МБ) для немедленной обратной связи. Это отсекает 90%+ базовых атак с печатью и экраном.\n- **Серверная:** запуск полной ансамблевой модели для окончательного скоринга живости. Это отсекает изощрённые атаки, включая 3D-маски и инъекции дипфейков.\n\nДвухуровневый подход обеспечивает **быструю обратную связь** (менее 500 мс на устройстве) при поддержании **высокой безопасности** (серверная часть перехватывает то, что пропускает edge).\n\n### 3. Биометрический движок сопоставления\n\nДвижок сопоставления сравнивает извлечённый лицевой шаблон с эталонным шаблоном в базе IKD. Для мандата на SIM это всегда **верификация 1:1** (не идентификация 1:N).\n\n**Конвейер сопоставления:**\n\n1. **Предобработка**: нормализация выравнивания лица, обрезка, изменение размера до входных размеров модели (112x112 или 160x160)\n2. **Извлечение признаков**: прогон через глубокую нейросеть (ArcFace, CosFace или аналог) для получения 128-512-мерного вектора эмбеддинга\n3. **Сравнение**: расчёт косинусного сходства или L2-расстояния между зондовым и эталонным эмбеддингами\n4. **Решение**: применение порога — обычно 0,4-0,6 косинусного сходства в зависимости от модели и требуемого FAR\n\n**Требования к производительности:**\n\n| Метрика | Требование |\n|---------|------------|\n| Время верификации 1:1 | \u003C 200 мс (серверная) |\n| Пропускная способность | > 1 000 верификаций\u002Fсек на узел |\n| FAR (коэффициент ложного принятия) | \u003C 0,001% |\n| FRR (коэффициент ложного отклонения) | \u003C 5% |\n| Размер шаблона | \u003C 2 КБ |\n\n### 4. Подсистема безопасного хранения и аудита\n\nВсе биометрические данные должны храниться и передаваться в соответствии с требованиями UU PDP и KOMDIGI:\n\n- **Шифрование шаблонов**: AES-256-GCM для шаблонов в состоянии покоя\n- **Управление ключами**: аппаратный модуль безопасности (HSM) или облачный KMS для ключей шифрования\n- **Передача**: TLS 1.3 с привязкой сертификатов для всех биометрических данных в транзите\n- **Журналы аудита**: неизменяемый, только для добавления журнал всех событий верификации\n- **Жизненный цикл данных**: шаблоны хранятся только на время верификации; логи — 5 лет\n\n## Соответствие требованиям Индонезии: UU PDP\n\n**Закон о защите персональных данных Индонезии (UU PDP, Закон № 27 от 2022 года)** классифицирует биометрические данные как **специфические персональные данные** (data pribadi yang bersifat spesifik), требующие усиленной защиты:\n\n### Обязанности контролёра данных\n\n| Обязанность | Реализация |\n|------------|------------|\n| Правовое основание | Явное согласие + нормативное соответствие (мандат KOMDIGI) |\n| Ограничение цели | Биометрические данные используются исключительно для верификации регистрации SIM |\n| Минимизация данных | Хранение шаблонов, а не необработанных изображений; удаление снимков после обработки |\n| Точность | Обеспечение актуальности шаблонов; повторная верификация каждые 5 лет |\n| Ограничение хранения | Логи: 5 лет; Шаблоны: срок действия SIM + 1 год |\n| Целостность и конфиденциальность | Шифрование AES-256, контроль доступа, уведомление о нарушениях в течение 72 часов |\n| Подотчётность | Ведение записей обработки, проведение DPIA, назначение DPO |\n\n### Трансграничная передача данных\n\nUU PDP **запрещает** передачу специфических персональных данных (включая биометрию) за пределы Индонезии, за исключением случаев:\n\n1. Страна назначения имеет эквивалентные законы о защите данных (KOMDIGI ведёт список одобренных стран)\n2. Действуют обязательные корпоративные правила\n3. Получено явное согласие субъекта данных\n\n**Практическое следствие:** вся инфраструктура обработки биометрии должна размещаться в **индонезийских дата-центрах**. Облачные провайдеры должны предлагать развёртывание в регионе Джакарта (AWS ap-southeast-3, GCP asia-southeast2, Azure Southeast Asia).\n\n## Масштабируемость: обслуживание 270+ млн населения\n\nИндонезия имеет **275,5 миллионов жителей** (оценка переписи 2025) и **345+ миллионов активных SIM-карт**. Система биометрической верификации должна масштабироваться для обработки:\n\n- **Пиковые новые регистрации**: 500 000 в день в период начального развёртывания\n- **Волна повторной верификации**: 200+ миллионов существующих SIM должны быть повторно верифицированы до июля 2027\n- **Устойчивое состояние**: 50 000-100 000 верификаций в день для новых SIM и замен\n\n### Архитектура горизонтального масштабирования\n\n```\n                    [Балансировщик нагрузки]\n                    \u002F      |      \\\n                   \u002F       |       \\\n            [Узел 1]  [Узел 2]  [Узел N]\n            (Rust)    (Rust)    (Rust)\n               |         |         |\n               +----+----+----+----+\n                    |         |\n              [PostgreSQL]  [Redis-кэш]\n              (Основной +    (Кэш шаблонов,\n               Реплики)      лимитирование,\n                              сессии)\n                    |\n              [Шлюз IKD]\n              (Лимитированный,\n               circuit-breaker)\n```\n\n### Планирование ёмкости\n\n| Компонент | Спецификация | Обоснование |\n|-----------|-------------|-------------|\n| API-узлы | 8-16 экземпляров (4 vCPU, 16 ГБ RAM) | 1 000 верификаций\u002Fсек\u002Fузел |\n| PostgreSQL | Основной + 2 реплики чтения (8 vCPU, 64 ГБ RAM) | Запись логов аудита + чтение шаблонов |\n| Redis | Кластер из 3 узлов (4 vCPU, 32 ГБ RAM) | Кэширование шаблонов, лимитирование |\n| Объектное хранилище | S3-совместимое (мин. 10 ТБ) | Зашифрованные снимки при обработке |\n| HSM | 2 экземпляра (active-passive) | Управление ключами шифрования |\n| Сеть | 1 Гбит\u002Fс выделенная, \u003C10 мс до IKD | Требование верификации в реальном времени |\n\n## Сравнение: обработка Edge vs Cloud\n\n| Фактор | Edge (на устройстве) | Cloud (серверная) | Рекомендация |\n|--------|---------------------|-------------------|--------------|\n| **Задержка** | \u003C500 мс | 1-3 с (зависит от сети) | Edge для UX |\n| **Точность** | 92-95% (ограниченная модель) | 98-99,5% (полная модель) | Cloud для решений |\n| **Безопасность** | Уязвимость к вмешательству в SDK | Полный контроль обработки | Cloud для соответствия |\n| **Пропускная способность** | Минимальная (только результат) | 100-500 КБ за верификацию | Edge для сельских районов |\n| **Стоимость** | Нулевая маржинальная стоимость | $0,01-0,05 за верификацию | Edge при масштабе |\n| **Совместимость устройств** | Требуется SDK для каждой платформы | Любое устройство с камерой | Cloud для универсальности |\n| **Цикл обновления** | Обзор App Store (1-7 дней) | Мгновенное серверное развёртывание | Cloud для гибкости |\n| **Офлайн-возможности** | Да (только живость) | Нет | Edge для пробелов связи |\n\n**Рекомендуемый гибридный подход для Индонезии:**\n\n1. **Edge**: валидация качества захвата + пассивная проверка живости (немедленная обратная связь)\n2. **Cloud**: активная валидация живости + извлечение шаблона + верификация IKD (авторитетное решение)\n\n## Безопасность: защита шаблонов и шифрование\n\n### Защита биометрических шаблонов\n\nНеобработанные биометрические шаблоны чувствительны — в случае кражи их нельзя заменить, как пароли. Реализуйте **отменяемую биометрию** с использованием необратимых преобразований:\n\n```rust\nuse aes_gcm::{Aes256Gcm, KeyInit, Nonce};\nuse aes_gcm::aead::Aead;\nuse rand::RngCore;\n\n\u002F\u002F\u002F Шифрование биометрического шаблона для хранения\nfn encrypt_template(\n    template: &[f32],\n    key: &[u8; 32],\n) -> Result\u003CEncryptedTemplate, CryptoError> {\n    let cipher = Aes256Gcm::new_from_slice(key)\n        .map_err(|_| CryptoError::InvalidKey)?;\n\n    \u002F\u002F Генерация случайного nonce (96 бит для GCM)\n    let mut nonce_bytes = [0u8; 12];\n    rand::thread_rng().fill_bytes(&mut nonce_bytes);\n    let nonce = Nonce::from_slice(&nonce_bytes);\n\n    \u002F\u002F Сериализация шаблона в байты\n    let template_bytes: Vec\u003Cu8> = template\n        .iter()\n        .flat_map(|f| f.to_le_bytes())\n        .collect();\n\n    \u002F\u002F Шифрование AES-256-GCM (обеспечивает аутентичность + конфиденциальность)\n    let ciphertext = cipher\n        .encrypt(nonce, template_bytes.as_ref())\n        .map_err(|_| CryptoError::EncryptionFailed)?;\n\n    Ok(EncryptedTemplate {\n        nonce: nonce_bytes.to_vec(),\n        ciphertext,\n        algorithm: \"AES-256-GCM\".to_string(),\n        created_at: chrono::Utc::now(),\n    })\n}\n```\n\n### Полный конвейер верификации на Rust\n\n```rust\nuse axum::{extract::State, Json};\nuse serde::{Deserialize, Serialize};\nuse uuid::Uuid;\nuse chrono::Utc;\n\n#[derive(Deserialize)]\nstruct VerificationRequest {\n    nik: String,\n    facial_image_base64: String,\n    device_id: String,\n    liveness_score: f64,\n    capture_metadata: CaptureMetadata,\n}\n\n#[derive(Serialize)]\nstruct VerificationResponse {\n    transaction_id: Uuid,\n    verified: bool,\n    confidence: f64,\n    processing_time_ms: u64,\n    timestamp: chrono::DateTime\u003CUtc>,\n}\n\nasync fn verify_biometric(\n    State(state): State\u003CAppState>,\n    Json(req): Json\u003CVerificationRequest>,\n) -> Result\u003CJson\u003CVerificationResponse>, AppError> {\n    let start = std::time::Instant::now();\n    let transaction_id = Uuid::new_v4();\n\n    \u002F\u002F Шаг 1: Валидация формата NIK (16 цифр)\n    if !is_valid_nik(&req.nik) {\n        return Err(AppError::InvalidNik);\n    }\n\n    \u002F\u002F Шаг 2: Декодирование и валидация изображения\n    let image_bytes = base64::decode(&req.facial_image_base64)\n        .map_err(|_| AppError::InvalidImage)?;\n    let quality = assess_image_quality(&image_bytes)?;\n    if quality.score \u003C 0.7 {\n        return Err(AppError::InsufficientImageQuality(quality));\n    }\n\n    \u002F\u002F Шаг 3: Серверная валидация живости\n    let liveness = state.liveness_engine\n        .validate(&image_bytes)\n        .await?;\n    if liveness.score \u003C 0.95 || liveness.is_attack {\n        return Err(AppError::LivenessCheckFailed);\n    }\n\n    \u002F\u002F Шаг 4: Извлечение биометрического шаблона\n    let template = state.biometric_engine\n        .extract_template(&image_bytes)\n        .await?;\n\n    \u002F\u002F Шаг 5: Верификация через IKD (с circuit breaker)\n    let ikd_result = state.ikd_circuit_breaker\n        .call(state.ikd_client.verify(\n            &req.nik, &template\n        ))\n        .await?;\n\n    \u002F\u002F Шаг 6: Запись журнала аудита\n    let elapsed = start.elapsed().as_millis() as u64;\n    state.audit_logger.log_verification(\n        transaction_id, &req.nik,\n        ikd_result.verified, ikd_result.confidence,\n        elapsed, &req.capture_metadata,\n    ).await?;\n\n    \u002F\u002F Шаг 7: Безопасное удаление необработанного изображения\n    drop(image_bytes);\n\n    Ok(Json(VerificationResponse {\n        transaction_id,\n        verified: ikd_result.confidence >= 0.95,\n        confidence: ikd_result.confidence,\n        processing_time_ms: elapsed,\n        timestamp: Utc::now(),\n    }))\n}\n```\n\n## Мониторинг и наблюдаемость\n\nПроизводственная биометрическая система должна иметь всеобъемлющий мониторинг:\n\n| Метрика | Порог оповещения | Назначение |\n|---------|-----------------|------------|\n| Успешность верификации | \u003C 90% | Обнаружение проблем системы или волн атак |\n| Среднее время обработки | > 3 секунд | Соответствие SLA |\n| Частота отклонений живости | > 15% | Обнаружение кампаний атак или проблем SDK |\n| Задержка шлюза IKD | > 2 секунд | Деградация инфраструктуры |\n| Состояние circuit breaker IKD | Open | Немедленное реагирование |\n| Ошибки шифрования шаблонов | > 0 | Проблемы HSM или управления ключами |\n| Ошибки записи журнала аудита | > 0 | Риск несоответствия |\n\n## Часто задаваемые вопросы\n\n### Какие языки программирования лучше всего подходят для систем биометрической верификации?\n\n**Rust** — отличный выбор для основного конвейера верификации благодаря гарантиям безопасности памяти, абстракциям нулевой стоимости и высокой производительности. Биометрический движок сопоставления выигрывает от способности Rust выполнять SIMD-оптимизированные векторные операции без пауз сборщика мусора. **Python** остаётся доминирующим для обучения ML-моделей и прототипирования. Для мобильного SDK требуются **Kotlin** (Android) и **Swift** (iOS), с **C\u002FC++** для кросс-платформенного биометрического ядра.\n\n### Как справиться с масштабом 270+ млн населения в базе сопоставления?\n\nПоскольку мандат на SIM в Индонезии использует **верификацию 1:1** (не идентификацию 1:N), масштаб базы управляем. Каждый запрос верификации ищет один NIK и сравнивает с одним хранимым шаблоном. Узким местом является не размер базы, а **параллельная пропускная способность**. При правильном индексировании поля NIK PostgreSQL обрабатывает 10 000+ поисков в секунду на скромном оборудовании.\n\n### В чём разница между AES-256-GCM и AES-256-CBC для шифрования шаблонов?\n\n**AES-256-GCM** настоятельно рекомендуется вместо CBC, поскольку обеспечивает **конфиденциальность и аутентичность** в одной операции (аутентифицированное шифрование с ассоциированными данными). GCM обнаруживает подделку шифротекста, а CBC — нет, что делает CBC уязвимым для атак padding oracle. GCM также быстрее на современных CPU с поддержкой инструкций AES-NI. Техническая спецификация KOMDIGI предписывает **аутентифицированное шифрование**, что делает GCM естественным выбором.\n\n### Может ли биометрическая верификация работать с существующей инфраструктурой e-KTP?\n\ne-KTP (электронное удостоверение личности) содержит **чип с биометрическими данными** (отпечатки пальцев и фотография лица). Однако мандат на SIM специально использует **цифровую платформу IKD**, а не считывание с физических чипов e-KTP. IKD предоставляет централизованную, актуальную базу данных, доступную через API, тогда как считывание чипов e-KTP требует NFC-оборудования и непрактично для высоконагруженных регистраций SIM.\n\n### Какова рекомендуемая стратегия аварийного восстановления?\n\nРеализуйте **мультирегиональную active-passive** конфигурацию в пределах Индонезии: основная площадка в **Джакарте** (AWS ap-southeast-3 или локальный дата-центр) с резервной в **Сурабае** или **Батаме**. Используйте потоковую репликацию PostgreSQL с **RPO менее 1 минуты** и **RTO менее 15 минут**. Ключи HSM должны быть реплицированы на площадку DR.\n\n### Как обеспечить справедливость и предотвратить предвзятость в распознавании лиц?\n\nТестирование на предвзятость критически важно для разнообразного населения Индонезии. Тестируйте систему по **типам кожи Фитцпатрика III-VI**, обоим полам, всем возрастным группам (18-80+) и с обычными аксессуарами (хиджаб, очки, маски). Процесс сертификации KOMDIGI включает **тестирование демографического паритета** — система должна обеспечивать отклонение точности не более 2% между демографическими группами.\n\n### Что происходит при утечке биометрических данных?\n\nПо UU PDP утечка с биометрическими данными требует: **уведомление органа по защите данных в течение 72 часов**, уведомление затронутых лиц без неоправданной задержки и подробный отчёт об инциденте. Скомпрометированные шаблоны должны быть **отозваны и перезарегистрированы** — вот почему отменяемая биометрия (необратимые преобразования шаблонов) критически важна. При надлежащей защите шаблонов утечка приводит к отзыву шаблонов, а не к постоянной компрометации личности.","\u003Ch2 id=\"\">Обзор архитектуры системы: краткий ответ\u003C\u002Fh2>\n\u003Cp>Совместимая система биометрической верификации для мандата на SIM-карты в Индонезии требует четырёх основных компонентов: \u003Cstrong>биометрический захват\u003C\u002Fstrong> (камера + SDK), \u003Cstrong>обработка живости\u003C\u002Fstrong> (PAD на устройстве или серверная), \u003Cstrong>сопоставление личности\u003C\u002Fstrong> (верификация 1:1 с базой IKD) и \u003Cstrong>безопасное хранение\u003C\u002Fstrong> (зашифрованные шаблоны с журналом аудита). Система должна обслуживать население свыше \u003Cstrong>270 миллионов человек\u003C\u002Fstrong>, обрабатывать верификации за \u003Cstrong>менее чем 3 секунды\u003C\u002Fstrong> и соответствовать как \u003Cstrong>Регламенту KOMDIGI № 7\u002F2026\u003C\u002Fstrong>, так и требованиям \u003Cstrong>UU PDP\u003C\u002Fstrong> по защите данных.\u003C\u002Fp>\n\u003Cp>Эта статья предоставляет детальный архитектурный чертёж для построения такой системы, включая проектирование компонентов, потоки данных, меры безопасности и паттерны реализации на Rust.\u003C\u002Fp>\n\u003Ch2 id=\"\">Основные компоненты\u003C\u002Fh2>\n\u003Ch3>1. Подсистема биометрического захвата\u003C\u002Fh3>\n\u003Cp>Подсистема захвата отвечает за получение качественного изображения лица пользователя. Качество напрямую влияет на точность последующих этапов — плохо освещённое, размытое изображение приведёт к отказу верификации даже для легитимного пользователя.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Требования:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Минимальное разрешение изображения: \u003Cstrong>640x480 пикселей\u003C\u002Fstrong> (VGA) для области лица\u003C\u002Fli>\n\u003Cli>Детекция лица: необходимо определить лицо в кадре и обрезать до стандартизированного размера\u003C\u002Fli>\n\u003Cli>Оценка качества: оценка освещения, угла позы, перекрытий и размытия перед продолжением\u003C\u002Fli>\n\u003Cli>Формат изображения: \u003Cstrong>JPEG\u003C\u002Fstrong> с качеством 80%+ или \u003Cstrong>PNG\u003C\u002Fstrong> для захвата без потерь\u003C\u002Fli>\n\u003Cli>Метаданные: временная метка захвата (ISO 8601), идентификатор устройства, GPS-координаты (с согласия пользователя), параметры камеры\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Пороги качества (соответствие ISO\u002FIEC 19794-5):\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Параметр\u003C\u002Fth>\u003Cth>Допустимый диапазон\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Угол рыскания\u003C\u002Ftd>\u003Ctd>-15° до +15°\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Угол тангажа\u003C\u002Ftd>\u003Ctd>-10° до +10°\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Угол крена\u003C\u002Ftd>\u003Ctd>-8° до +8°\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Расстояние между глазами\u003C\u002Ftd>\u003Ctd>≥ 90 пикселей\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Освещение\u003C\u002Ftd>\u003Ctd>100-250 люкс на лице\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Размытие (дисперсия Лапласиана)\u003C\u002Ftd>\u003Ctd>> 100\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Доля площади лица\u003C\u002Ftd>\u003Ctd>> 20% кадра\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>2. Подсистема обработки живости\u003C\u002Fh3>\n\u003Cp>Подсистема живости определяет, получен ли захваченный биометрический образец от живого человека. Для мандата Индонезии она должна соответствовать стандартам \u003Cstrong>ISO\u002FIEC 30107-3 Уровень 2\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Архитектурное решение: Edge vs Сервер\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Для индонезийского рынка рекомендуется \u003Cstrong>гибридный подход\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>На устройстве (edge):\u003C\u002Fstrong> запуск облегчённой модели живости (MobileFaceNet или аналог, <30 МБ) для немедленной обратной связи. Это отсекает 90%+ базовых атак с печатью и экраном.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Серверная:\u003C\u002Fstrong> запуск полной ансамблевой модели для окончательного скоринга живости. Это отсекает изощрённые атаки, включая 3D-маски и инъекции дипфейков.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Двухуровневый подход обеспечивает \u003Cstrong>быструю обратную связь\u003C\u002Fstrong> (менее 500 мс на устройстве) при поддержании \u003Cstrong>высокой безопасности\u003C\u002Fstrong> (серверная часть перехватывает то, что пропускает edge).\u003C\u002Fp>\n\u003Ch3>3. Биометрический движок сопоставления\u003C\u002Fh3>\n\u003Cp>Движок сопоставления сравнивает извлечённый лицевой шаблон с эталонным шаблоном в базе IKD. Для мандата на SIM это всегда \u003Cstrong>верификация 1:1\u003C\u002Fstrong> (не идентификация 1:N).\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Конвейер сопоставления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Предобработка\u003C\u002Fstrong>: нормализация выравнивания лица, обрезка, изменение размера до входных размеров модели (112x112 или 160x160)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Извлечение признаков\u003C\u002Fstrong>: прогон через глубокую нейросеть (ArcFace, CosFace или аналог) для получения 128-512-мерного вектора эмбеддинга\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Сравнение\u003C\u002Fstrong>: расчёт косинусного сходства или L2-расстояния между зондовым и эталонным эмбеддингами\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Решение\u003C\u002Fstrong>: применение порога — обычно 0,4-0,6 косинусного сходства в зависимости от модели и требуемого FAR\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Cstrong>Требования к производительности:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Метрика\u003C\u002Fth>\u003Cth>Требование\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Время верификации 1:1\u003C\u002Ftd>\u003Ctd>< 200 мс (серверная)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Пропускная способность\u003C\u002Ftd>\u003Ctd>> 1 000 верификаций\u002Fсек на узел\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>FAR (коэффициент ложного принятия)\u003C\u002Ftd>\u003Ctd>< 0,001%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>FRR (коэффициент ложного отклонения)\u003C\u002Ftd>\u003Ctd>< 5%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Размер шаблона\u003C\u002Ftd>\u003Ctd>< 2 КБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>4. Подсистема безопасного хранения и аудита\u003C\u002Fh3>\n\u003Cp>Все биометрические данные должны храниться и передаваться в соответствии с требованиями UU PDP и KOMDIGI:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Шифрование шаблонов\u003C\u002Fstrong>: AES-256-GCM для шаблонов в состоянии покоя\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Управление ключами\u003C\u002Fstrong>: аппаратный модуль безопасности (HSM) или облачный KMS для ключей шифрования\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Передача\u003C\u002Fstrong>: TLS 1.3 с привязкой сертификатов для всех биометрических данных в транзите\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Журналы аудита\u003C\u002Fstrong>: неизменяемый, только для добавления журнал всех событий верификации\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Жизненный цикл данных\u003C\u002Fstrong>: шаблоны хранятся только на время верификации; логи — 5 лет\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"uu-pdp\">Соответствие требованиям Индонезии: UU PDP\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Закон о защите персональных данных Индонезии (UU PDP, Закон № 27 от 2022 года)\u003C\u002Fstrong> классифицирует биометрические данные как \u003Cstrong>специфические персональные данные\u003C\u002Fstrong> (data pribadi yang bersifat spesifik), требующие усиленной защиты:\u003C\u002Fp>\n\u003Ch3>Обязанности контролёра данных\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Обязанность\u003C\u002Fth>\u003Cth>Реализация\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Правовое основание\u003C\u002Ftd>\u003Ctd>Явное согласие + нормативное соответствие (мандат KOMDIGI)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Ограничение цели\u003C\u002Ftd>\u003Ctd>Биометрические данные используются исключительно для верификации регистрации SIM\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Минимизация данных\u003C\u002Ftd>\u003Ctd>Хранение шаблонов, а не необработанных изображений; удаление снимков после обработки\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Точность\u003C\u002Ftd>\u003Ctd>Обеспечение актуальности шаблонов; повторная верификация каждые 5 лет\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Ограничение хранения\u003C\u002Ftd>\u003Ctd>Логи: 5 лет; Шаблоны: срок действия SIM + 1 год\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Целостность и конфиденциальность\u003C\u002Ftd>\u003Ctd>Шифрование AES-256, контроль доступа, уведомление о нарушениях в течение 72 часов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Подотчётность\u003C\u002Ftd>\u003Ctd>Ведение записей обработки, проведение DPIA, назначение DPO\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Трансграничная передача данных\u003C\u002Fh3>\n\u003Cp>UU PDP \u003Cstrong>запрещает\u003C\u002Fstrong> передачу специфических персональных данных (включая биометрию) за пределы Индонезии, за исключением случаев:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Страна назначения имеет эквивалентные законы о защите данных (KOMDIGI ведёт список одобренных стран)\u003C\u002Fli>\n\u003Cli>Действуют обязательные корпоративные правила\u003C\u002Fli>\n\u003Cli>Получено явное согласие субъекта данных\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Cstrong>Практическое следствие:\u003C\u002Fstrong> вся инфраструктура обработки биометрии должна размещаться в \u003Cstrong>индонезийских дата-центрах\u003C\u002Fstrong>. Облачные провайдеры должны предлагать развёртывание в регионе Джакарта (AWS ap-southeast-3, GCP asia-southeast2, Azure Southeast Asia).\u003C\u002Fp>\n\u003Ch2 id=\"270\">Масштабируемость: обслуживание 270+ млн населения\u003C\u002Fh2>\n\u003Cp>Индонезия имеет \u003Cstrong>275,5 миллионов жителей\u003C\u002Fstrong> (оценка переписи 2025) и \u003Cstrong>345+ миллионов активных SIM-карт\u003C\u002Fstrong>. Система биометрической верификации должна масштабироваться для обработки:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Пиковые новые регистрации\u003C\u002Fstrong>: 500 000 в день в период начального развёртывания\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Волна повторной верификации\u003C\u002Fstrong>: 200+ миллионов существующих SIM должны быть повторно верифицированы до июля 2027\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Устойчивое состояние\u003C\u002Fstrong>: 50 000-100 000 верификаций в день для новых SIM и замен\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Архитектура горизонтального масштабирования\u003C\u002Fh3>\n\u003Cpre>\u003Ccode>                    [Балансировщик нагрузки]\n                    \u002F      |      \\\n                   \u002F       |       \\\n            [Узел 1]  [Узел 2]  [Узел N]\n            (Rust)    (Rust)    (Rust)\n               |         |         |\n               +----+----+----+----+\n                    |         |\n              [PostgreSQL]  [Redis-кэш]\n              (Основной +    (Кэш шаблонов,\n               Реплики)      лимитирование,\n                              сессии)\n                    |\n              [Шлюз IKD]\n              (Лимитированный,\n               circuit-breaker)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Планирование ёмкости\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Компонент\u003C\u002Fth>\u003Cth>Спецификация\u003C\u002Fth>\u003Cth>Обоснование\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>API-узлы\u003C\u002Ftd>\u003Ctd>8-16 экземпляров (4 vCPU, 16 ГБ RAM)\u003C\u002Ftd>\u003Ctd>1 000 верификаций\u002Fсек\u002Fузел\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>PostgreSQL\u003C\u002Ftd>\u003Ctd>Основной + 2 реплики чтения (8 vCPU, 64 ГБ RAM)\u003C\u002Ftd>\u003Ctd>Запись логов аудита + чтение шаблонов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Redis\u003C\u002Ftd>\u003Ctd>Кластер из 3 узлов (4 vCPU, 32 ГБ RAM)\u003C\u002Ftd>\u003Ctd>Кэширование шаблонов, лимитирование\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Объектное хранилище\u003C\u002Ftd>\u003Ctd>S3-совместимое (мин. 10 ТБ)\u003C\u002Ftd>\u003Ctd>Зашифрованные снимки при обработке\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>HSM\u003C\u002Ftd>\u003Ctd>2 экземпляра (active-passive)\u003C\u002Ftd>\u003Ctd>Управление ключами шифрования\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Сеть\u003C\u002Ftd>\u003Ctd>1 Гбит\u002Fс выделенная, <10 мс до IKD\u003C\u002Ftd>\u003Ctd>Требование верификации в реальном времени\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"edge-vs-cloud\">Сравнение: обработка Edge vs Cloud\u003C\u002Fh2>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Фактор\u003C\u002Fth>\u003Cth>Edge (на устройстве)\u003C\u002Fth>\u003Cth>Cloud (серверная)\u003C\u002Fth>\u003Cth>Рекомендация\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>\u003Cstrong>Задержка\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd><500 мс\u003C\u002Ftd>\u003Ctd>1-3 с (зависит от сети)\u003C\u002Ftd>\u003Ctd>Edge для UX\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Точность\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>92-95% (ограниченная модель)\u003C\u002Ftd>\u003Ctd>98-99,5% (полная модель)\u003C\u002Ftd>\u003Ctd>Cloud для решений\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Безопасность\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>Уязвимость к вмешательству в SDK\u003C\u002Ftd>\u003Ctd>Полный контроль обработки\u003C\u002Ftd>\u003Ctd>Cloud для соответствия\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Пропускная способность\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>Минимальная (только результат)\u003C\u002Ftd>\u003Ctd>100-500 КБ за верификацию\u003C\u002Ftd>\u003Ctd>Edge для сельских районов\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Стоимость\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>Нулевая маржинальная стоимость\u003C\u002Ftd>\u003Ctd>$0,01-0,05 за верификацию\u003C\u002Ftd>\u003Ctd>Edge при масштабе\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Совместимость устройств\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>Требуется SDK для каждой платформы\u003C\u002Ftd>\u003Ctd>Любое устройство с камерой\u003C\u002Ftd>\u003Ctd>Cloud для универсальности\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Цикл обновления\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>Обзор App Store (1-7 дней)\u003C\u002Ftd>\u003Ctd>Мгновенное серверное развёртывание\u003C\u002Ftd>\u003Ctd>Cloud для гибкости\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Офлайн-возможности\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>Да (только живость)\u003C\u002Ftd>\u003Ctd>Нет\u003C\u002Ftd>\u003Ctd>Edge для пробелов связи\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>\u003Cstrong>Рекомендуемый гибридный подход для Индонезии:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Edge\u003C\u002Fstrong>: валидация качества захвата + пассивная проверка живости (немедленная обратная связь)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Cloud\u003C\u002Fstrong>: активная валидация живости + извлечение шаблона + верификация IKD (авторитетное решение)\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"\">Безопасность: защита шаблонов и шифрование\u003C\u002Fh2>\n\u003Ch3>Защита биометрических шаблонов\u003C\u002Fh3>\n\u003Cp>Необработанные биометрические шаблоны чувствительны — в случае кражи их нельзя заменить, как пароли. Реализуйте \u003Cstrong>отменяемую биометрию\u003C\u002Fstrong> с использованием необратимых преобразований:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-rust\">use aes_gcm::{Aes256Gcm, KeyInit, Nonce};\nuse aes_gcm::aead::Aead;\nuse rand::RngCore;\n\n\u002F\u002F\u002F Шифрование биометрического шаблона для хранения\nfn encrypt_template(\n    template: &[f32],\n    key: &[u8; 32],\n) -> Result<EncryptedTemplate, CryptoError> {\n    let cipher = Aes256Gcm::new_from_slice(key)\n        .map_err(|_| CryptoError::InvalidKey)?;\n\n    \u002F\u002F Генерация случайного nonce (96 бит для GCM)\n    let mut nonce_bytes = [0u8; 12];\n    rand::thread_rng().fill_bytes(&mut nonce_bytes);\n    let nonce = Nonce::from_slice(&nonce_bytes);\n\n    \u002F\u002F Сериализация шаблона в байты\n    let template_bytes: Vec<u8> = template\n        .iter()\n        .flat_map(|f| f.to_le_bytes())\n        .collect();\n\n    \u002F\u002F Шифрование AES-256-GCM (обеспечивает аутентичность + конфиденциальность)\n    let ciphertext = cipher\n        .encrypt(nonce, template_bytes.as_ref())\n        .map_err(|_| CryptoError::EncryptionFailed)?;\n\n    Ok(EncryptedTemplate {\n        nonce: nonce_bytes.to_vec(),\n        ciphertext,\n        algorithm: \"AES-256-GCM\".to_string(),\n        created_at: chrono::Utc::now(),\n    })\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Полный конвейер верификации на Rust\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-rust\">use axum::{extract::State, Json};\nuse serde::{Deserialize, Serialize};\nuse uuid::Uuid;\nuse chrono::Utc;\n\n#[derive(Deserialize)]\nstruct VerificationRequest {\n    nik: String,\n    facial_image_base64: String,\n    device_id: String,\n    liveness_score: f64,\n    capture_metadata: CaptureMetadata,\n}\n\n#[derive(Serialize)]\nstruct VerificationResponse {\n    transaction_id: Uuid,\n    verified: bool,\n    confidence: f64,\n    processing_time_ms: u64,\n    timestamp: chrono::DateTime<Utc>,\n}\n\nasync fn verify_biometric(\n    State(state): State<AppState>,\n    Json(req): Json<VerificationRequest>,\n) -> Result<Json<VerificationResponse>, AppError> {\n    let start = std::time::Instant::now();\n    let transaction_id = Uuid::new_v4();\n\n    \u002F\u002F Шаг 1: Валидация формата NIK (16 цифр)\n    if !is_valid_nik(&req.nik) {\n        return Err(AppError::InvalidNik);\n    }\n\n    \u002F\u002F Шаг 2: Декодирование и валидация изображения\n    let image_bytes = base64::decode(&req.facial_image_base64)\n        .map_err(|_| AppError::InvalidImage)?;\n    let quality = assess_image_quality(&image_bytes)?;\n    if quality.score < 0.7 {\n        return Err(AppError::InsufficientImageQuality(quality));\n    }\n\n    \u002F\u002F Шаг 3: Серверная валидация живости\n    let liveness = state.liveness_engine\n        .validate(&image_bytes)\n        .await?;\n    if liveness.score < 0.95 || liveness.is_attack {\n        return Err(AppError::LivenessCheckFailed);\n    }\n\n    \u002F\u002F Шаг 4: Извлечение биометрического шаблона\n    let template = state.biometric_engine\n        .extract_template(&image_bytes)\n        .await?;\n\n    \u002F\u002F Шаг 5: Верификация через IKD (с circuit breaker)\n    let ikd_result = state.ikd_circuit_breaker\n        .call(state.ikd_client.verify(\n            &req.nik, &template\n        ))\n        .await?;\n\n    \u002F\u002F Шаг 6: Запись журнала аудита\n    let elapsed = start.elapsed().as_millis() as u64;\n    state.audit_logger.log_verification(\n        transaction_id, &req.nik,\n        ikd_result.verified, ikd_result.confidence,\n        elapsed, &req.capture_metadata,\n    ).await?;\n\n    \u002F\u002F Шаг 7: Безопасное удаление необработанного изображения\n    drop(image_bytes);\n\n    Ok(Json(VerificationResponse {\n        transaction_id,\n        verified: ikd_result.confidence >= 0.95,\n        confidence: ikd_result.confidence,\n        processing_time_ms: elapsed,\n        timestamp: Utc::now(),\n    }))\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">Мониторинг и наблюдаемость\u003C\u002Fh2>\n\u003Cp>Производственная биометрическая система должна иметь всеобъемлющий мониторинг:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Метрика\u003C\u002Fth>\u003Cth>Порог оповещения\u003C\u002Fth>\u003Cth>Назначение\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Успешность верификации\u003C\u002Ftd>\u003Ctd>< 90%\u003C\u002Ftd>\u003Ctd>Обнаружение проблем системы или волн атак\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Среднее время обработки\u003C\u002Ftd>\u003Ctd>> 3 секунд\u003C\u002Ftd>\u003Ctd>Соответствие SLA\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Частота отклонений живости\u003C\u002Ftd>\u003Ctd>> 15%\u003C\u002Ftd>\u003Ctd>Обнаружение кампаний атак или проблем SDK\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Задержка шлюза IKD\u003C\u002Ftd>\u003Ctd>> 2 секунд\u003C\u002Ftd>\u003Ctd>Деградация инфраструктуры\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Состояние circuit breaker IKD\u003C\u002Ftd>\u003Ctd>Open\u003C\u002Ftd>\u003Ctd>Немедленное реагирование\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Ошибки шифрования шаблонов\u003C\u002Ftd>\u003Ctd>> 0\u003C\u002Ftd>\u003Ctd>Проблемы HSM или управления ключами\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Ошибки записи журнала аудита\u003C\u002Ftd>\u003Ctd>> 0\u003C\u002Ftd>\u003Ctd>Риск несоответствия\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"\">Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3 id=\"\">Какие языки программирования лучше всего подходят для систем биометрической верификации?\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Rust\u003C\u002Fstrong> — отличный выбор для основного конвейера верификации благодаря гарантиям безопасности памяти, абстракциям нулевой стоимости и высокой производительности. Биометрический движок сопоставления выигрывает от способности Rust выполнять SIMD-оптимизированные векторные операции без пауз сборщика мусора. \u003Cstrong>Python\u003C\u002Fstrong> остаётся доминирующим для обучения ML-моделей и прототипирования. Для мобильного SDK требуются \u003Cstrong>Kotlin\u003C\u002Fstrong> (Android) и \u003Cstrong>Swift\u003C\u002Fstrong> (iOS), с \u003Cstrong>C\u002FC++\u003C\u002Fstrong> для кросс-платформенного биометрического ядра.\u003C\u002Fp>\n\u003Ch3 id=\"270\">Как справиться с масштабом 270+ млн населения в базе сопоставления?\u003C\u002Fh3>\n\u003Cp>Поскольку мандат на SIM в Индонезии использует \u003Cstrong>верификацию 1:1\u003C\u002Fstrong> (не идентификацию 1:N), масштаб базы управляем. Каждый запрос верификации ищет один NIK и сравнивает с одним хранимым шаблоном. Узким местом является не размер базы, а \u003Cstrong>параллельная пропускная способность\u003C\u002Fstrong>. При правильном индексировании поля NIK PostgreSQL обрабатывает 10 000+ поисков в секунду на скромном оборудовании.\u003C\u002Fp>\n\u003Ch3 id=\"aes-256-gcm-aes-256-cbc\">В чём разница между AES-256-GCM и AES-256-CBC для шифрования шаблонов?\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>AES-256-GCM\u003C\u002Fstrong> настоятельно рекомендуется вместо CBC, поскольку обеспечивает \u003Cstrong>конфиденциальность и аутентичность\u003C\u002Fstrong> в одной операции (аутентифицированное шифрование с ассоциированными данными). GCM обнаруживает подделку шифротекста, а CBC — нет, что делает CBC уязвимым для атак padding oracle. GCM также быстрее на современных CPU с поддержкой инструкций AES-NI. Техническая спецификация KOMDIGI предписывает \u003Cstrong>аутентифицированное шифрование\u003C\u002Fstrong>, что делает GCM естественным выбором.\u003C\u002Fp>\n\u003Ch3 id=\"e-ktp\">Может ли биометрическая верификация работать с существующей инфраструктурой e-KTP?\u003C\u002Fh3>\n\u003Cp>e-KTP (электронное удостоверение личности) содержит \u003Cstrong>чип с биометрическими данными\u003C\u002Fstrong> (отпечатки пальцев и фотография лица). Однако мандат на SIM специально использует \u003Cstrong>цифровую платформу IKD\u003C\u002Fstrong>, а не считывание с физических чипов e-KTP. IKD предоставляет централизованную, актуальную базу данных, доступную через API, тогда как считывание чипов e-KTP требует NFC-оборудования и непрактично для высоконагруженных регистраций SIM.\u003C\u002Fp>\n\u003Ch3 id=\"\">Какова рекомендуемая стратегия аварийного восстановления?\u003C\u002Fh3>\n\u003Cp>Реализуйте \u003Cstrong>мультирегиональную active-passive\u003C\u002Fstrong> конфигурацию в пределах Индонезии: основная площадка в \u003Cstrong>Джакарте\u003C\u002Fstrong> (AWS ap-southeast-3 или локальный дата-центр) с резервной в \u003Cstrong>Сурабае\u003C\u002Fstrong> или \u003Cstrong>Батаме\u003C\u002Fstrong>. Используйте потоковую репликацию PostgreSQL с \u003Cstrong>RPO менее 1 минуты\u003C\u002Fstrong> и \u003Cstrong>RTO менее 15 минут\u003C\u002Fstrong>. Ключи HSM должны быть реплицированы на площадку DR.\u003C\u002Fp>\n\u003Ch3 id=\"\">Как обеспечить справедливость и предотвратить предвзятость в распознавании лиц?\u003C\u002Fh3>\n\u003Cp>Тестирование на предвзятость критически важно для разнообразного населения Индонезии. Тестируйте систему по \u003Cstrong>типам кожи Фитцпатрика III-VI\u003C\u002Fstrong>, обоим полам, всем возрастным группам (18-80+) и с обычными аксессуарами (хиджаб, очки, маски). Процесс сертификации KOMDIGI включает \u003Cstrong>тестирование демографического паритета\u003C\u002Fstrong> — система должна обеспечивать отклонение точности не более 2% между демографическими группами.\u003C\u002Fp>\n\u003Ch3 id=\"\">Что происходит при утечке биометрических данных?\u003C\u002Fh3>\n\u003Cp>По UU PDP утечка с биометрическими данными требует: \u003Cstrong>уведомление органа по защите данных в течение 72 часов\u003C\u002Fstrong>, уведомление затронутых лиц без неоправданной задержки и подробный отчёт об инциденте. Скомпрометированные шаблоны должны быть \u003Cstrong>отозваны и перезарегистрированы\u003C\u002Fstrong> — вот почему отменяемая биометрия (необратимые преобразования шаблонов) критически важна. При надлежащей защите шаблонов утечка приводит к отзыву шаблонов, а не к постоянной компрометации личности.\u003C\u002Fp>\n","ru","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:33.918063Z","Построение систем биометрической верификации для Индонезии: архитектура и паттерны Rust","Глубокое техническое руководство по архитектуре систем биометрической верификации для мандата KOMDIGI на SIM. Компоненты системы, соответствие UU PDP, паттерны масштабирования, шифрование AES-256 и примеры кода на Rust.","система биометрической верификации архитектура индонезия",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000008","AI","ai","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000011","Biometrics","biometrics",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000013","Security","security","Биометрия",[37,44,50],{"id":38,"title":39,"slug":40,"excerpt":41,"locale":12,"category_name":42,"published_at":43},"d0200000-0000-0000-0000-000000000013","Почему Бали становится хабом импакт-технологий Юго-Восточной Азии в 2026 году","pochemu-bali-stanovitsya-khabom-impakt-tekhnologiy-2026","Бали занимает 16-е место среди стартап-экосистем Юго-Восточной Азии. Растущая концентрация Web3-разработчиков, ИИ-стартапов в области устойчивого развития и компаний в сфере эко-тревел-технологий формирует нишу столицы импакт-технологий региона.","Инженерия","2026-03-28T10:44:37.953039Z",{"id":45,"title":46,"slug":47,"excerpt":48,"locale":12,"category_name":42,"published_at":49},"d0200000-0000-0000-0000-000000000012","Защита данных в ASEAN: чек-лист разработчика для мультистранового комплаенса","zashchita-dannykh-asean-chek-list-razrabotchika-komplaens","Семь стран ASEAN имеют собственные законы о защите данных с разными моделями согласия, требованиями к локализации и штрафами. Практический чек-лист для разработчиков мультистрановых приложений.","2026-03-28T10:44:37.944001Z",{"id":51,"title":52,"slug":53,"excerpt":54,"locale":12,"category_name":42,"published_at":55},"d0200000-0000-0000-0000-000000000011","Цифровая трансформация Индонезии на $29 миллиардов: возможности для софтверных компаний","tsifrovaya-transformatsiya-indonezii-29-milliardov-vozmozhnosti-dlya-kompaniy","Рынок IT-услуг Индонезии вырастет с $24,37 млрд в 2025 году до $29,03 млрд в 2026 году. Облачная инфраструктура, искусственный интеллект, электронная коммерция и дата-центры обеспечивают самый быстрый рост в Юго-Восточной Азии.","2026-03-28T10:44:37.917095Z",{"id":13,"name":57,"slug":58,"bio":59,"photo_url":19,"linkedin":19,"role":60,"created_at":61,"updated_at":61},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]