Розробка портала державної організації
Державні портали являють собою окрему категорію з конкретними вимогами. Законодавство про забезпечення доступу до інформації про діяльність державних органів, стандарти доступності (WCAG 2.1, рівень AA як мінімум), інтеграція з системами державної ідентифікації та строгі вимоги до захисту персональних даних. Це не корпоративний веб-сайт із формою зв'язку — він вимагає вищого рівня відповідальності при реалізації.
Законодавча база
Вимоги щодо доступності WCAG 2.1 рівня AA обов'язкові для державних портальних рішень у більшості країн. Вимірювання та перевірка здійснюються як автоматично (axe-core, Lighthouse), так і вручну.
Перелік обов'язкових розділів для державних органів встановлюється законодавством: інформація про орган, нормативні документи, державні послуги, результати перевірок та матеріали з боротьби проти корупції.
Доступність: WCAG 2.1 AA обов'язково
Це не рекомендація, а вимога. Перевірка проводиться як автоматично, так і вручну.
Типові проблеми, які виявляються під час аудиту:
<!-- Неправильно: пошукова форма без label -->
<input type="search" placeholder="Пошук на сайті">
<!-- Правильно -->
<label for="site-search" class="sr-only">Пошук на сайті</label>
<input id="site-search" type="search" placeholder="Пошук на сайті"
role="searchbox" aria-label="Пошук на сайті">
<!-- Неправильно: таблиця без заголовків -->
<table>
<tr><td>Іванов І.І.</td><td>Начальник відділу</td><td>+38 01 000-00-00</td></tr>
</table>
<!-- Правильно: заголовки з атрибутом scope -->
<table>
<caption>Контакти керівництва</caption>
<thead>
<tr>
<th scope="col">Повне ім'я</th>
<th scope="col">Посада</th>
<th scope="col">Телефон</th>
</tr>
</thead>
<tbody>
<tr>
<td>Іванов Іван Іванович</td>
<td>Начальник відділу</td>
<td><a href="tel:+38010000000">+38 01 000-00-00</a></td>
</tr>
</tbody>
</table>
Усі PDF-документи, розміщені на порталі, також мають бути доступними — теговані PDF-файли з логічною структурою та alt-текстами для зображень у документі. Це окрема робота при наявності великого архіву.
Аутентифікація через державні сервіси
Для порталів із особистими кабінетами громадян обов'язкова інтеграція із системою державної ідентифікації. Це залежить від країни та може включати інтеграцію через SAML 2.0 або OpenID Connect.
Приклад інтеграції через OAuth 2.0 (спрощена схема):
// Laravel: переспрямування на авторизацію
public function redirectToAuth()
{
$params = [
'client_id' => config('auth.client_id'),
'response_type' => 'code',
'scope' => 'openid fullname email mobile',
'redirect_uri' => route('auth.callback'),
'state' => csrf_token(),
'timestamp' => now()->format('Y.m.d H:i:s O'),
'access_type' => 'online',
];
// Підпис запиту через PKCS#7 (обов'язково)
$params['client_secret'] = $this->signRequest($params);
return redirect(config('auth.auth_url') . '?' . http_build_query($params));
}
Система вимагає підписи запитів за допомогою кваліфікованого сертифіката — це окрема інфраструктура, яку потрібно отримувати в центрі сертифікації.
Персональні дані та зберігання
Законодавство вимагає зберігання персональних даних громадян на серверах у межах країни. Це впливає на вибір хостингу — тільки вітчизняні дата-центри для відповідних проектів.
# Обов'язкові заголовки безпеки для державного портала
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{NONCE}'; style-src 'self' 'unsafe-inline'" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
Пошук за документами
Державні портали накопичують тисячі нормативних документів. Простий пошук по БД недостатній — потрібен повнотекстовий пошук з урахуванням морфології мови.
Elasticsearch із плагіном для морфологічного аналізу або PostgreSQL із конфігурацією для локальної мови:
-- PostgreSQL: повнотекстовий пошук з морфологічним аналізом
CREATE INDEX docs_fts_idx ON documents
USING GIN (to_tsvector('english', title || ' ' || content));
SELECT id, title,
ts_rank(to_tsvector('english', title || ' ' || content), query) AS rank
FROM documents, to_tsquery('english', 'privatization & housing') query
WHERE to_tsvector('english', title || ' ' || content) @@ query
ORDER BY rank DESC
LIMIT 20;
Для дуже великих архівів (>100k документів) — Elasticsearch із налаштованим аналізатором:
{
"settings": {
"analysis": {
"analyzer": {
"language_analyzer": {
"type": "custom",
"tokenizer": "standard",
"filter": ["lowercase", "stop", "morphology"]
}
}
}
}
}
Версіонування та архів
Нормативні документи мають зберігатися з історією редакцій. Користувачі мають бачити поточну версію та мати доступ до попередніх. Це реалізується через таблицю редакцій:
CREATE TABLE document_revisions (
id BIGSERIAL PRIMARY KEY,
document_id BIGINT REFERENCES documents(id),
content TEXT NOT NULL,
revision_note TEXT,
created_by BIGINT REFERENCES users(id),
created_at TIMESTAMPTZ DEFAULT NOW(),
effective_from DATE,
effective_to DATE
);
Багатомовність
Для організацій, які працюють із національними меншинами або міжнародними партнерами, портал повинен підтримувати кілька мов. hreflang у head, окремі URL за мовою (/uk/, /en/, /de/), localStorage для збереження мовних переваг.
Продуктивність та SLA
Державні портали мають дотримуватися SLA по доступності — зазвичай 99.5% або вище. Це означає:
- резервування на рівні інфраструктури (кілька серверів за балансувальником навантаження)
- моніторинг uptime з сигналізацією
- регламент реагування на інциденти
Типова схема: nginx як зворотний проксі та балансувальник, два application-сервери в режимі active-active, PostgreSQL з репліцією, Redis для кешування сесій.
Терміни
Інформаційний портал із документальним архівом і пошуком — 6–10 тижнів. З інтеграцією державних систем та особистими кабінетами громадян — 3–5 місяців. Повнофункціональна платформа державних послуг із прийманням заяв, статусом звернень та електронним підписом — окремий проект на 6+ місяців з участю юристів та фахівців з інформаційної безпеки.