All posts by Bozho

Няколко електронни препоръки към банките

Post Syndicated from Bozho original https://blog.bozho.net/blog/3582

Когато говорим за електронно управление, си представяме основно държавната администрация. Само че има още два вида участници (които са записани и в Закона за електронното управление) – лица, осъществяващи публични функции и доставчици на обществени услуги.

Пример за първото са нотариуси, частни съдебни изпълнители и като цяло – лица, на които държавата чрез закон е възложила някакви функции. Обществените услуги са малко по-разтегливи, но законът изрежда следните: „образователни, здравни, водоснабдителни, канализационни, топлоснабдителни, електроснабдителни, газоснабдителни, телекомуникационни, пощенски, банкови, финансови и удостоверителни“. Банковите и удостоверителните бяха добавени изрично с измененията в закона през 2016г, но логически винаги са попадали там. Най-вече, защото банките в много случаи участват или в процеса по предоставяне на административни услуги, или изискват (понякога по силата на закон) данни и обстоятелства, които са резултат от административни услуги (удостоверения, например).

И докато критиката ни за липса на автоматизация и удобство за гражданите е основно насочена към администрацията, то банките също имат доста неща, които да подобрят. С тази публикация ще направя няколко предложения към банките, с които да подобрят и тяхната работа, и удобството за гражданите, а и законовото им съответствие.

  • Автоматично извличане на данни от първични администратори – банките понякога искат предоставяне на данни от страна на гражданите за ползване на някоя услуга, като например удостоверение за семейно положение, удостоверение за наследници, декларация по ЗМИП, дори до преди известно време и актуално състояние. Банките могат, а и е редно, да извличат тези данни от първичните администратори, дали през публичен интерфейс, както е с Търговския регистър, дали през системата за междурегистров обмен RegiX. Банките имат право на това, като доставчик на обществени услуги, и би било много добре да спрат да искат неща. Няколко пъти съм обяснявал на банкови служители, че не могат да искат от мен да предоставям или декларирам данни, които са вписани в Търговския регистър, и че дори подлежат на глоба. Когато се извличат такива данни, задължително трябва да е ясно кой е служителят и системата и за какво се ползват, за да се избегнат злоупотреби. RegiX пази одитна следа на всички такива действия именно с тази цел. Автоматичното извличане на такива данни може да стане и през електронното банкиране (или други онлайн услуги), след като гражданите успешно се идентифицират през националната схема за електронна идентификация (която все още я няма) или през системата за е-автентикация. Същият подход може да се ползва и при KYC (know your customer) процедури – няма нужда клиентът да си описва всичките данни, при положение, че по номер на лична карта могат да се извлекат от регистъра на МВР.
  • Приемане на електронни документи – интеграцията с първични регистри е дълго усилие и отнема време. Но приемането на електронни документи, издадени от администрацията, е законово задължение. За съжаление има много оплаквания, че някоя банка не е приела електронно-подписано удостоверение и е накарала човека да отиде да си го вземе от администрацията с „мокър печат“. Банката е длъжна да приеме електронния документ, тъй като той е валидно обективиран индивидуален административен акт. Администрацията с триста зора е електронизирала дадена услуга, предоставила е електронен документ на гражданина, обаче се оказва, че той не му върши работа, защото някакви вътрешни правила някъде искат мокър печат – това не е приемливо, не е и законно, и намалява интереса и ползването на и без това рядко използваните електронни административни услуги
  • Автоматично обновяване на фирмени профили – фирмите си откриват сметки, след това се случват промени (сменен управител, сменена форма на дружеството и др.) Банките могат (и трябва) да се абонират за промените в Търговския регистър (към момента става с получаване на един XML файл с всички промени за деня) и да обновяват вътрешните си бази данни, вместо да искат от клиентите да го правят. Това от една страна спестява усилия на клиентите, а от друга – спестява главоболия при смяна на управител. Старият управител все още има достъп до електронното банкиране и може да нарежда преводи, а новият може и да не се сети веднага да отиде и да обнови данните в банката (или в банките, защото често фирмите имат сметки в повече от една банка).
  • Използване на електронен печат в е-банкирането – документите, удостоверяващи извършено плащане, са нужни на много места – понякога неправомерно (администрацията знае, че е получила пари, няма нужда, а и право, да иска „бележка“), понякога правомерно – например, при увеличаване на капитал на дружество се изисква доказване, че капиталът е внесен. Електронните банкирания е добре да могат да поставят електронен печат (по смисъла на Регламент (ЕС) 910/2014) върху платежните, така че те да могат да бъдат ползвани в електронен вид. В момента трябва да отидеш до банката и там да ти сложат печат. В някои случаи трябва сам да си носиш разпечатаното платежно, защото те нямат достъп. Електронният печат би решил този проблем, удостоверявайки от името на титуляра на печата – банката – че това платежно е истинско и непроменено.
  • Избягване на еднократни пароли за подписване на преводи – това е сложна и дълга тема, но в общия случай 6-цифрени кодове не дават т.нар. non-repudiation, т.е. свойството на електронните подписи, според което авторът не може да се отрече от извършеното действие. Тъй като те обикновено разчитат на споделен криптографски ключ, а в случай на sms дори цялата информация е при банката, то служител на банката, имащ достъп до ключа, може да нареди превод от името на клиента. На теория, но това е достатъчно за оспорване на транзакции (да, със „з“). Да, на база на други фактори, като IP адреси в логове, сметка на получателя и др. може да се подкрепи едно или друго твърдение, но злонамерен клиент може да маскира следите си достатъчно добре и да твърди, че банката, имайки достъп до споделения криптографски ключ, е наредила превода вместо него. Как да стане по-сигурно – приложенията, които банките ползват, могат да ползват асиметрична криптография, така че подписването да става с ключ, с който банката не разполага. Детайлите тук са много важни и сложни, така че няма да се спиран на тях, но е нещо, за което е добре да се помисли и да се отчетат рисковете.
  • Автоматизиране на процесите по ЗМИП – Законът за мерките срещу изпиране на пари (който е следствие от европейска директива), предвижда възможност за електронна комуникация между банките и ДАНС. Наскоро се появи казус, свързан с тегленето на пари от Васил Божков, тъй като ДАНС отричаше да е получавал уведомление. Няма да навлизам в спецификите на ЗМИП, но тъй като електронната комуникация е само възможност, но не и задължение, практиките са различни и понякога дори включват ръчни процеси. Автоматизирането на процесите по докладване на транзакции по ЗМИП няма общо с електронното управление или удобството за гражданите, но би спестило ситуации, като споменатата преди малко. Тук, разбира се, зависи и от ДАНС какво точно ще приемат.

Винаги има какво да се подобри в процесите на една организация, а банките са големи и всяка промяна на процес е по-трудна, отколкото изглежда отстрани. Но все пак, с оглед и на законовите възможности, би ми се искало да видя горните предложения реализирани все по-често. Те имат техническия капацитет и нерядко визията за дигитализация, така че би трябвало препоръки като горните да са в графата „технически детайли“.

Философията на електронното управление, от която винаги съм се водил, включва интегриране на всички участници в процесите, а не само на администрацията. В Естония, например, банките са били от водещите в процеса на изграждане на тяхното електронно управление. В горните предложения не съм добавил унифициране на средствата за електронна идентификация на клиенти, защото национална схема за електронна идентификация все още няма, но когато тя се появи би било най-логично всички банки да я припознаят (както в Естония), като така подпомогнат и нейното навлизане и за други нужди.

Seven Legacy Integration Patterns

Post Syndicated from Bozho original https://techblog.bozho.net/seven-legacy-integration-patterns/

If we have to integrate two (or more) systems nowadays, we know – we either use an API or, more rarely, some message queue.

Unfortunately, many systems in the world do not support API integration. And many more a being created as we speak, that don’t have APIs. So when you inevitably have to integrate with them, you are left with imperfect choices to make. Below are seven patterns to integrate with legacy systems (or not-so-legacy systems that are built in legacy ways).

Initially I wanted to use “bad integration patterns”. But if you don’t have other options, they are not bad – they are inevitable. What’s bad is that fact that so many systems continue to be built without integration in mind.

I’ve seen all of these, on more than one occasion. And I’ve heard many more stories about them. Unfortunately, they are not the exception (fortunately, they are also not the rule, at least not anymore).

  1. Files on FTP – one application uploads files (XML, CSV, other) to an FTP (or other shared resources) and the other ones reads them via a scheduled job, parses them and optionally spits a response – either in the same FTP, or via email. Sharing files like that is certainly not ideal in terms of integration – you don’t get real-time status of your request, and other aspects are trickier to get right – versioning, high availability, authentication, security, traceability (audit trail).
  2. Shared database – two applications sharing the same database may sound like a recipe for disaster, but it’s not uncommon to see it in the wild. If you are lucky, one application will be read-only. But breaking changes to the database structure and security concerns are major issues. You can only use this type of integration is you expose your database directly to another application, which you normally don’t want to do.
  3. Full daily dump – instead of sharing an active database, some organizations do a full dump of their data every day or week and provide to to the other party for import. Obvious data privacy issues exist with that, as it’s a bad idea to have full dumps of your data flying around (in some cases on DVDs or portable HDDs), in addition to everything mention below – versioning, authentication, etc.
  4. Scraping – when an app has no API, it’s still possible to extract data from it or push data to it – via the user interface. With web applications that’s easier, as they “speak” HTML and HTTP. With desktop apps, screen scraping has emerged as an option. The so-called RPA software (Robotic process automation) relies on all types of scraping to integrate legacy systems. It’s very fragile and requires complicated (and sometimes expensive) tooling to get right. Not to mention the security aspect, which requires storing credentials in non-hashed form somewhere in order to let the scraper login.
  5. Email – when the sending or receiving system don’t support other forms of integration, email comes as a last resort. If you can trigger something by connecting a mailbox or if an email is produced after some event happens in the sending system, this may be all you need to integrate. Obviously, email is a very bad means of integration – it’s unstructured, it can fail for many reasons, and it’s just not meant for software integration. You can attach structured data, if you want to get extra inventive, but if you can get both ends to support the same format, you can probably get them extended to support proper APIs.
  6. Adapters – you can develop a custom module that has access to the underlying database, but exposes a proper API. That’s an almost acceptable solution, as you can have a properly written (sort-of) microservice independent of the original application and other system won’t know they are integrating with a legacy piece of software. It’s tricky to get it right in some cases, however, as you have to understand well the state space of the database. Read-only is easy, writing is much harder or next to impossible.
  7. Paper – no, I’m not making this up. There are cases where one organizations prints some data and then the other organization (or department) receives the paper documents (by mail or otherwise) and inputs them in their system. Expensive projects exist out there that aim to remove the paper component and introduce actual integration, as paper-based input is error-prone and slow. The few legitimate scenarios for a paper-based step is when you need an extra security and the paper trail, combined with the fact that paper is effectively airgapped, may give you that. But even then it shouldn’t be the only transport layer.

If you need to do any of the above, it’s usually because at least one of the system is stuck and can’t be upgraded. It’s either too legacy to touch, or the vendor is gone, or adding an API is “not on their roadmap” and would be too expensive.

If you are building a system, always provide an API. Some other system will have to integrate with it, sooner or later. It’s not sustainable to build close systems and delay the integration question for when it’s needed. Assume it’s always needed.

Fancy ESBs may be able to patch things quickly with one of the approaches above and integrate the “unintegratable”, but heavy reliance on an ESB is an indicator of too many legacy or low-quality systems.

But simply having an API doesn’t cut it either. If you don’t support versioning and backward-compatible APIs, you’ll be in an even more fragile state, as you’ll be breaking existing integrations as you progress.

Enterprise integration is tricky. But, as with many things in software, it’s best handled in the applications that we build. If we build them right, things are much easier. Otherwise, organizations have to revert to the legacy approaches mentioned above and introduce complexity, fragility, security and privacy risks and a general feeling of low-quality that has to be supported by increasingly unhappy people.

The post Seven Legacy Integration Patterns appeared first on Bozho's tech blog.

Using Multiple Dynamic Caches With Spring

Post Syndicated from Bozho original https://techblog.bozho.net/using-multiple-dynamic-caches-with-spring/

In a third post about cache managers in spring (over a long period of time), I’d like to expand on the previous two by showing how to configure multiple cache managers that dynamically create caches.

Spring has CompositeCacheManager which, in theory, should allow using more than one cache manager. It works by asking the underlying cache managers whether they have a cache with the requested name or not. The problem with that is when you need dynamically-created caches, based on some global configuration. And that’s the common scenario, when you don’t want to manually define caches, but instead want to just add @Cacheable and have spring (and the underlying cache manager) create the cache for you with some reasonable defaults.

That’s great until you need to have more than one cache managers. For example – one for local cache and one for a distributed cache. In many cases a distributed cache is needed; however not all method calls need to be distributed – some can be local to the instance that handles it and you don’t want to burden your distributed cache with stuff that can be kept locally. Whether you can configure a distributed cache provider to designate some cache to be local, even though it’s handled by the distributed cache provider – maybe, but I don’t guarantee it will be trivial.

So, faced with that issue, I had to devise some simple mechanism of designating some caches as “distributed” and some as “local”. Using CompositeCacheManager alone would not do it, so I extended the distributed cache manager (in this case, Hazelcast, but it can be done with any provider):

/**
 * Hazelcast cache manager that handles only cache names with a specified prefix for distributed caches
 */
public class OptionalHazelcastCacheManager extends HazelcastCacheManager {

    private static final String DISTRIBUTED_CACHE_PREFIX = "d:";

    public OptionalHazelcastCacheManager(HazelcastInstance hazelcast) {
        super(hazelcast);
    }

    @Override
    public Cache getCache(String name) {
        if (name == null || !name.startsWith(DISTRIBUTED_CACHE_PREFIX)) {
            return null;
        }

        return super.getCache(name);
    }
}

And the corresponding composite cache manager configuration:

    <bean id="cacheManager" class="org.springframework.cache.support.CompositeCacheManager">
        <property name="cacheManagers">
            <list>
                <bean id="hazelcastCacheManager" class="com.yourcompany.util.cache.OptionalHazelcastCacheManager">
                    <constructor-arg ref="hazelcast" />
                </bean>

                <bean id="caffeineCacheManager" class="com.yourcompany.util.cache.FlexibleCaffeineCacheManager">
                    <property name="cacheSpecification" value="expireAfterWrite=10m"/>
                    <property name="cacheSpecs">
                        <map>
                            <entry key="statistics" value="expireAfterWrite=1h"/>
                        </map>
                    </property>
                </bean>
            </list>
        </property>
    </bean>

That basically means that any cache with a name starting with d: (for “distributed”) should be handled by the distributed cache manager. Otherwise, proceed to the next cache manager (Caffeine in this case). So when you want to define a method with a cacheable result, you have to decide whether it’s @Cacheable("d:cachename") or just @Cacheable("cachename")

That’s probably one of many ways to approach that issue, but I like it for its simplicity. Caching is hard (distributed caching even more so), and while we are lucky to have Spring abstract most of that, we sometimes have to handle special cases ourselves.

The post Using Multiple Dynamic Caches With Spring appeared first on Bozho's tech blog.

Дилемите на конструктивната опозиция

Post Syndicated from Bozho original https://blog.bozho.net/blog/3579

Миналия месец в свое обаждане до Фрогнюз, Андрей Зографски от Спаси София е казал, че ГЕРБ и Демократична България са внесли заедно доклад за дигитализация. Обаждането е било в контекста на провокативно заглавие от Фрогнюз, което е „прикачало“ Спаси София за Фандъкова, заради пиар събитието, на което заедно представиха проекта за Патриарха. И тезата е била „а като те внасят заедно няма проблем“.

Това, че е внесен доклад с ГЕРБ е невярно твърдение. Няма такъв. Само че нека развия малко темата за конструктивната опозиция.

През декември ДБ внесе доклад за дигитализация, а през януари поиска създаване на работна група, която да направи общ доклад с внесената от ГЕРБ стратегия (която е с по-широк обхват; тази на ДБ се фокусираше предимно върху електронно управление, защото без тези основи, другите неща са по-скоро „научна фантастика“).

Участвах в няколкото срещи на работната група, в която имаше общински съветници, ресорния зам.кмет и експерти. Работата беше конструктивна, възприеха се направените предложения и финалният вариант на документа съдържа необходимите цели, а бъдещата пътна карта (върху която също работи работната група) съдържа и доста конкретика, чрез която да се гарантират целите.

Аз от 5 години като развален телефон повтарям за острата нужда от удобна и масова електронната идентификация, така че идентифицирах това като основен риск пред реализацията на повечето проекти. Предложението (идващо и от предизборната програма) за софийско приложение за eID, което вбъдеще да се интегрира с националната схема, беше оставено за решаване след анализ на възможностите.

В крайна сметка Демократична България е опозиция и реши да не бъде съвносител на доклада за стратегията (т.е. точно обратното на това, което Зографски от Спаси София казва). Съвносителството е символично в случая, но би дало повече публичност на усилията, които бяха вложени от нас в процеса. Отказът от съвносителство е и отказ от „пиар“.

Дълга, деликатна и дискусионна е темата как една опозиция да бъде конструктивна, без да бъде „прилапана“ от управляващите. Аз нямам еднозначен отговор, но мисля, че когато важното е да се свърши работа, приписването на заслуги и снимките в медиите идват на втори план.

При всички положения слухове ще има – щом дори наблюдаващите отблизо процеса си мислят, че ДБ е съвносител (не твърдя, че Зографски лъже – просто не знае).

Трудно е да се намери точката, в която по-опозиционно настроените граждани да одобрят нещо заедно с тези, които искат да бъде вършена работа. Но както при всяка тема, „нищо не вършите“ и „гушнахте се с управляващите“ не са единствените опции, а двата края на един спектър. Комуникационна е задачата да се позиционираш по този спектър. И рискът с едно непремерено действие да отидеш в единия му край не е малък.

Пътната карта на ЦИК за дистанционно електронно гласуване е недоразумение

Post Syndicated from Bozho original https://blog.bozho.net/blog/3576

ЦИК е публикувала „Пътна карта за изпълнение на експериментално дистанционно електронно гласуване“. До 2023-та. Документът е ужасяващо неадекватен:

  1. В него се казва, че „КЕП е с ниско(то) ниво на сигурност“. Това е пълна глупост. Съвсем лесно проверимо невярно твърдение и базово знание относно Регламент (ЕС) 910/2014. КЕП (квалифицираният електронен подпис) задължително използва най-сигурни хардуерни устройства за съхранение на криптографските ключове и организациите, които го издават, преминават регулярни одити на информационната си сигурност. Използването на КЕП за провеждане на експериментите беше вариантът, който и нормативната уредба предвижда, и който аз съм и казвал поне 3-4 пъти, но те отказваха.
  2. Друг „аргумент“ е, че в КЕП се съдържало ЕГН-то в явен вид. Не се казва това защо е проблем (при положение, че ЕГН-то може да се прочете само след като титулярът на КЕП-а подпише нещо и съответно данни от сертификата се изпратят на другата страна). Да, в националната схема за електронна идентификация се предвижда ЕГН-то и други данни да не се съдържат в носителя, но това няма отношение към е-гласуването.
  3. Уж пътна карта, а единственият срок е крайният – 2023. Има 10 етапа, но за никой няма дори индикативен срок кога трябва да започне и кога трябва да свърши. „Когато-тогава“ е залегнало като основен принцип.
  4. Няма никакво обяснение защо за проект с одобрено финансиране от 2017г (което се съдържа в сигнатурата на проекта), по оперативна програма, която приключва 2020г, и чийто срок е бил 2019г, се пише пътна карта до … 2023г.
  5. Документът явно е писан от някой, който тепърва се учи как се използва Word и как трябва да изглеждат документите. Нито един нов ред или празно пространство, никакво автоматично номериране, нито една таблица, никакво подчертаване и стилизиране на важните точки. Документ, който не е писан да се чете, а „да го има“.

Винаги съм казвал, че електронното гласуване не е проста работа. Даже е сложна, академично сложна. И трябва към него да се подхожда с много премерен ентусиазъм и да се оценяват всички рискове. Да се действа бавно и внимателно.

Това, което прави ЦИК, обаче, е мърлящина, която да институционализира политическия страх и безидейност.

Low-Code, Rapid Application Development and Digital Transformation

Post Syndicated from Bozho original https://techblog.bozho.net/low-code-rapid-application-development-and-digital-transformation/

Recently, many low-code/no-code solutions have gained speed in the enterprise, giving non-technical people the option to create simple applications. Analysts predict that the low-code industry will grow by 20+% each year. But what is low-code, why is it getting so popular and what are the issues with it?

Low-code is something that we’ve occasionally seen in the past decades – a drag-and-drop UI designer that allows you to create simple applications without coding skills. Products have matured and practically all offer similar features – the ability to design entity relationships in drag-and-drop entity-relationship diagrams, the ability to design UI via WYSIWYG, to design simple processes via BPMN-like notations, to call external services via importing web service definitions, to choose from pre-baked entity definitions and to fetch and store data in external databases and spreadsheets.

There are many tools in this domain – MS PowerApps, OutSystems, Appian, Mendix, Google’s recently acquired AppSheets, Ninox, WaveMaker, and many more. And they may differ slightly in their approach and in their feature set, but the whole point is to be able to easily create applications (web-based, mobile-based, hybrid) that solve some immediate pain that these users have, where going through a full-blown IT project with the associated development cost is an overkill.

And that sounds great – you don’t have to rely on the overly busy and not often too responsive IT department in your non-IT company, you just build something yourself to optimize your immediate problem and to digitize your paper processes. And it can do that. To be honest, I like the idea of such tools existing, because a large portion of digital transformation is not handled well by huge, centralized systems and years long development projects. A lot of agility is required in a landscape where there’s more and more demand for digital transformation with expensive developers with limited availability. We have to admit that professional developers can’t be everywhere and solve every problem that could be solved by information technology. And so such tools democratize digital transformation, allowing non-technical people to create software.

Or at least that’s the theory. In practice this is challenging in many ways:

  • Some technical knowledge required – it’s cool to be able to draw an entity relationship diagrams, but first you need to know what a data model is. It’s nice to be able to import a web service and be able to call it, but you have to know what a web service is. Integrating user directories implies you know what LDAP/AD is. I’m not sure non-technical people are able to make real use of these capabilities. Some tools still require simple code even to open a new dialog, and you have to copy-paste that code from somewhere.
  • Integration with on-premise systems – building something useful almost always requires integrating with an existing system. It’s fine to assume everything is in “the cloud”, but even the cloud can be seen as on-premise from the perspective of a 3rd party SaaS. Many tools that I’ve seen integrate with databases by supplying IP, username and password – something that is almost never the case and is a bad idea. The ability to connect to something within the orgnaization’s infrastructure (even if that infrastructure is on Azure and you are using MS PowerApps) means permissions, networks rules configuration, accounts, approvals. And you have to know what to request in order to get it.
  • Vendor lock-in – most low-code tools use proprietary formats for meta-descriptions (some go so far as to store binary representation of their metadata in a local sqlite database, for example). Some providers allow you to run the application on your own cloud by installing their server-side application, but some are purely SaaS. Once you build an application with one tool, you can’t really switch to another. Nice exceptions are WaveMaker and Skyve which generate actual Java code which you can download at any time. Is that lock-in bad? Well, yes – if it happens that you need a feature that’s not yet available, or an integration that’s not yet there, you are stuck.
  • Shadow IT – all IT in an organization is assumed to be managed and observed by the IT department. In terms of monitoring, security, compliance, data protection, lifecycle management, technical support, etc. With low-code these applications can exist without the IT department even knowing about them and that poses many risks (which I’ll discuss below)
  • Sustainability – what if a low-code company goes out of business, or gets acquired by someone who decides to sunset a product or a set of features? What happens when the employee that created the low-code app leaves and there’s nobody that knows how to “program” with the selected tool in order to support the app? What happens when the low-code app becomes legacy itself? Because of the vendor-lock in and lack of any standardization, it’s a big risk to take in terms of sustainability. Sure, you’ll solve an immediate problem somehow, but you may create many more down the line.
  • Security – on the one hand, using a PaaS/SaaS may be perceived as coming with built-in security. On the other hand, non-technical people can’t assess the security of a given platform. And security can’t be fully “built-in” – you have to make sure that authentication is required, that apps are not visible outside some whitelisted office locations, that data can’t be exported by unauthorized people, that you have protection against XSS, CSRF, SQLi and whatnot. Even if the platform gives these options, a non-technical person doesn’t know they have to take care of them in the first place.
  • Compliance – many industries are regulated and there are horizontal regulations like the data protection ones (GDPR, CCPA). Data breaches often happen because data was fetched from its original well-protected storage and kept in various places (like a low-code app) that the data protection officer doesn’t know about. Encryption, anonymization, data minimization, retention periods – most low-code solutions don’t support these things out of the box and it’s unlikely that an employee not familiar with the specifics will walk the extra mile to have the app compliant.
  • Bugs outside of your control – when you have a bug in your software, you can fix it. If it’s in a library, you can patch it. If it’s in a set of tools of a third-party platform, you can’t do anything. During my testing of several low-code solutions I stumbled upon many bugs and inconsistencies.

Some of these problems exist in regular projects as well. Developers may not know how to make an application GDPR-compliant, security is too often overlooked in many projects, and technologies are sometimes selected without taking sustainability into account. But these problems are aggravated by low-code solutions.

The interesting thing is that low-code is one part of a broader spectrum of technologies. They start with “Rapid application development” (RAD) tools and frameworks and end with “no-code” (a.k.a. less feature-rich no-code alternatives). Code-generation tools like Spring Roo are RAD, OpenXava is a RAD framework. Some low-code tools can actually be seen as RAD tools – the aforementioned WaveMaker can be used pretty easily by dev teams to quickly deliver simpler projects without sacrificing too much control (and I guess it is, being acquired by an software development company).

Then there’s RPA – “robotic process automation”, which I’ll bluntly simplify as “low-code with screen scraping” – you automate some processes that involve legacy systems with which you can only extract information and perform actions by having “bots” press buttons on screens. RPA lies slightly outside the rapid application development spectrum, but it brings one important point – there are RPA developers. People that are not deeply technical and aren’t as qualified as developers, but who can still automate processes using the RPA tools. Same goes for low-code and some flavors of RAD – it is assumed that you don’t have to be technical to develop something, but actually there can be (and there are) dedicated experts that can build stuff with these tools. They are not actual developers, but if you can deliver a project with 5 low-code developers and one actual developer, this can dramatically cut costs.

Developers and large companies certainly have a “toolbox” which they reuse across projects – snippets from here and there, occasionally some library or microservice. But each new project involves a lot of boilerplate that even developers need to get rid of. I’m certainly not a big fan of code generation, but RAD has some merit that we have to explore it in order to improve efficiency without sacrificing quality. And to be able to provide the simple tools that would otherwise be built with sub-optimal low-code approaches.

Blurring the line between “developer” and “non-developer” is already happening, though. And while focusing on our fancy frameworks, we shouldn’t lose sight on the tools for the less technically skilled; if only because there’s a risk we’ll have to support them in the long run. And because they will become part of a software ecosystem with which our software will have to interact.

Whether that’s the right and sustainable approach to digital transformation, I don’t know. I’d prefer, of course, everyone to be able to code at least simple things with the help of advanced RAD tools. And we’ll probably get there in a few decades. But as digital transformation needs to happen now, we may have to work with what we have and try to make it more secure, compliant, with less vendor lock-in and more visibility for the IT departments. Otherwise we risk creating an even bigger mess than we are at now.

The post Low-Code, Rapid Application Development and Digital Transformation appeared first on Bozho's tech blog.

Електронно управление в криза

Post Syndicated from Bozho original https://blog.bozho.net/blog/3570

Електронното управление в последните 20 години се развива „под радара“, като от време на време излиза някоя новина колко милиони са похарчени и как нищо не работи. С уговорката, че изхарченото трудно може да се сметне без задълбочен анализ, наблюдението е до голяма степен вярно – гражданите не могат да ползват електронни услуги, а процесите в администрацията не са оптимизирани. Това не значи, че електронни услуги няма – напротив. Но тяхното използване е възможно само от въоръжени с търпение, технически умения и понякога нормативни познания.

Администрацията от своя страна не е свикнала на електронния начин на работа. Често електронният подпис „не е истински подпис“, изискват се печати, а гражданите са подканвани да дойдат на място да си свършат работата. Това е следствие от много фактори, някои от които са липса на техническа подготовка и липса на управленско желание в съответния орган.

Основната причина, обаче, е липсата на търсене. Светлина в тази посока хвърля проучване на Галъп Интернешънъл по поръчка на Държавна агенция „Електронно управление“ от края на 2017 г. 59% от анкетираните нямат и не възнамеряват да имат средство за ползване на е-услуги (електронен подпис, ПИК и др.), а 77.6% изобщо не са търсили информация за електронни услуги. Все още липсва очакването, че държавата може и трябва да обслужва гражданите онлайн.

Това, което извънредното положение започва да променя е именно това търсене. Опашките пред НОИ за издаване на ПИК, ръстът на издадени електронни подписи и ръстът на заявени електронни услуги, въпреки многото техни несъвършенства – всичко това е логично следствие от нуждата да си комуникираш с държавата онлайн. И все повече хора осъзнават, че канали за това съществуват. Администрацията също се движи спрямо търсенето – отстранява технически проблеми в движение, отстранява административни пречки.

За бизнеса нещата се променят по-малко, тъй като той и до момента има възможност да прави много неща онлайн – комуникацията с НАП и Агенция по вписванията е до голяма степен електронна. Повечето бизнеси отавна имат и квалифицирани електорнни подписи, така че за тях пречките са по-малко. В момента е важно програмите за бизнеса, свързани с кризата, да бъдат разработени по дигитален начин, така че да не създават допълнителна тежест.

В последните 5 години, след законодателни инициативи и създаването на Държавна агенция „Електронно управление“, бавно инфраструктурата на електронното управление започна да се стабилизира. Бяха централизирани и нормативно уредени някои ключови аспекти, като обмена на електронни документи между администрациите, автоматичното извличане на информация от първични регистри, сигурното връчване на електронни документи. Ключови системи все още не са създадени или надградени, но отстрани липсата им се вижда по-трудно.

Това, което продължава видимо да липсва, е масово и удобно средство за електронна идентификация, чрез което да могат да се използват услугите. МВР закъсня ужасно с тази инициатива, което оказва влияние върху възможността „апетитът да дойде с яденето“. Мозайката от опции (ПИК, ПИН, КЕП, облачен КЕП), всяка със своите проблеми, в момента слага таван на реалното използване на е-услуги.

За тези, които все пак имат някое от наличните средства, възможностите са доста – много институции имат електронни услуги на сайтовете си, съществува системата за сигурно електронно връчване, както и по-структурираната система за електронни форми, откъдето десетки администрации предоставят услуги. За целта трябва да бъде свален един PDF, попълнен, подписан и качен обратно. Именно подписването е другата спънка. То е логически различно от идентификацията, но технически може да бъде реализирано по същия начин. Възможността това да се случи без използване на КЕП е ключова за широкото използване на наличните възможности.

Дали кризата ще увеличи търсенето достатъчно много, че структурирано решение на проблема с идентификацията и подписването да бъде най-накрая формулирано и реализирано, предстои да разберем.

(статията е публикувана с редакции в сп. Мениджър)

Six Things I Learned from Mr. Robot

Post Syndicated from Bozho original https://techblog.bozho.net/six-things-i-learned-from-mr-robot/

Mr. Robot is an amazingly accurate series about a hacker (Elliot Alderson) and his, uhm, undertakings. The series is consulted by many cybersecurity experts and so every hack that happens is actually properly executed, using real tools and commands that do exactly what an infosec expert would expect. Nothing shown on screen is the usual bullshit TV hacking. And that is awesome and scary in a number of ways.

Obviously, this post is full of spoilers, so SPOILER ALERT, if you haven’t watched it, go and do that and then continue reading. Another disclaimer I have to make is that you should use the tools and techniques below only for ethical hacking, penetration testing and other legal activities.

The series has many hacks happening, from connecting to a neighbor’s WiFi, guessing people’s social media passwords and installing malware via flash drives, to complex social engineering plots, an HSM hack, the use of steganography and other advanced stuff. There’s even a tool pack with everything that’s used in the series. I’m fairly well-versed in the cybersecurity domain so even though I haven’t performed any hacks, most of the things happening on screen were familiar. But I did learn some interesting things from the series, which I’d like to share, as they sparked my interest and made me read a bit more. Many hacking scenes require you to pause and try to read what’s on screen, but that makes it even more fun.

  • proxychains – many tools are in use in the series, and Kali Linux is often used. But I wasn’t familiar with one particular tool that I think is crucial. Proxychains. I know, I’m a n00b to have never heard about it. What it does is basically running every command via a SOCKS or HTTP proxy. By default it uses Tor, but as Elliot knows that the NSA might be watching the Tor exit nodes, he switches to a regular proxy to execute the main attack in Season 1. proxychains curl https://google.com would open Google via the pre-configured proxy. This is very important to avoid being caught, and makes attribution and forensics much harder. To be fair, I didn’t see exactly where Elliot uses proxychains, but several people claim he uses it. Even if it’s not on the show, I learned about it after reading about the hacks, so it counts.
  • shred -z – I know and I’ve used the shred command. However, I didn’t know it has a “-z” argument which “add a final overwrite with zeros to hide shredding”. I guess there are more of these minor tool options here and there, but that’s an important point about covering one’s tracks. If you don’t do the zeroing, eventually, with proper forensics, they might discover that something was there (and was shredded).
  • How encryption ransomware works – ransomware that encrypts all your files and then asks for bitcoin in order to decrypt them is something fairly known. However, I didn’t know exactly how these ransomeware programs work – e.g. what they use for encryption. It appears that Darlene may have modified CryptoLocker in order to encrypt E Corp’s data. I was interested by that because at the end of season 3 Elliot finds a key that can undo the hack that rendered E Corp’s data unusable and he sends an RSA private key (via ProtonMail). Why would they encrypt something with RSA if they explicitly said they used AES? Well, it turns out that Cryptolocker (and others) work by generating one AES key per file, encrypting the file, then encrypting the AES key with the RSA public key and storing the encrypted AES key alongside the file. That’s a sensible approach because the private key never leaves the attacker and can’t be intercepted. But using asymmetric encryption to encrypt large volumes is not a good idea (it’s slow). So whenever asymmetric encryption is used, it’s always used to encrypt a symmetric key that is then used to encrypt/decrypt the actual data. And the fact that they reused existing ransomware rather than creating something from scratch allowed Mr. Robot to keep the RSA private key (that can be used to decrypt everything) rather than throwing it away.
  • UPS devices explode – I guess I’m just not good with hardware. I used to own a UPS, and I know it’s a battery and batteries sometimes malfunction (hello, Samsung), but the fact that the firmware controls important physical parameters that could in theory lead to the UPS exploding was not something I had thought about (shame on me, especially given that for one semester I’ve been taking chemistry classes). The answers in this thread are interesting – basically it’s absolutely expected for a UPS to explode (just not all of them at the same time). In the end, it’s very unlikely that the particular hack would succeed, but exploding UPSs are a reality. And that is an important point – you can’t trust your hardware either.
  • IMSI catchers – while I’m aware that mobile communication standards (SS7) are insecure, but I didn’t know exactly how. I’ve worked on telecom projects, but more on the business logic/billing side, so I was unaware of devices available to be used for MITM attacks. IMSI catchers allow intercepting one’s mobile phone communication based on the fact that mobile phones try to optimize their coverage combined with the lack of cell authentication. The bottom line here is you can’t rely on plain calls or SMS to be secure. So don’t use SMS for 2FA (shown as weak in season 4). Basically, use Signal.
  • HSM “cloning” – this is а complicated scene that shows how Angela copies keys from an HSM. It’s explained in detail here and here. The premise of the hack was that Elliot had upgraded the UPS firmware to only accept updates that are signed by E Corp’s private key. That means that you can’t compromise them unless you own the keys; however the keys are stored on a hardware security module that doesn’t allow them to be copied. I knew what an HSM is and what it does; what I didn’t know is the procedure for performing an HSM backup. It turns out they used an actual SafeNet HSM to backup the original one, which then allowed them to sign whatever they wanted on behalf of E Corp. The private keys never left the HSMs, of course (which is the whole point of HSMs), but by backing it up on one that’s controlled by the adversary, they effectively “leaked” the keys. The HSM backup procedure is complex and requires USB keys to unlock certain stages of the process. Normally these keys should be stored in safes (and not lying around, as depicted), but not strictly following procedures is not uncommon in organizations.

The scary thing about the series is that although it’s fiction, everything is realistic. Every hack depicted can happen in real life, and probably has happened. The social engineering parts may be a bit optimistic, but they are entirely plausible. The “wildest” hacks require some suspension of disbelief but even they are theoretically possible at least. The feeling that everything can be hacked and exploited is, unfortunately, realistic. You get that same feeling after watching a few DEF CON or CCC talks. And that’s why cybersecurity is important. Because things that are not hacked yet are not safe, they are just not interesting enough.

The post Six Things I Learned from Mr. Robot appeared first on Bozho's tech blog.

Критика в криза: за хейта, конструктивната критика и прогнилата държава

Post Syndicated from Bozho original https://blog.bozho.net/blog/3551

От средата на март държавата е в извънредно положение във връзка с пандемията. Извънредното положение има своето отражение върху обществения живот – излишно е да ги посочвам, всички ги усещаме. Има обаче една деликатна тема – как да реагираме като граждани на мерките на щаба и правителството – както на идеята им, така и на реализацията им. Да ги приемаме като абсолютно необходими в кризисна ситуация, без да ги поставяме под съмнение? Да ги атакуваме и „хейтим“, защото са „поредната глупост“? Да приемаме техните несъвършенства в сложната ситуация?

Аз предимно ги приемам, отчитайки несъвършенствата им и сложната и неизвестна среда, в която трябва да работи националния оперативен щаб. Нормално е да следим какво правят европейските ни партньори и да правим като тях, нормално е да нямаме отговори на всички въпроси, нормално е да има комуникационни пропуски. И съм склонен да се съглася с Борисов, че може би най-важната мярка, заради която нямаме сериозен ръст на случаите е, че достатъчно рано бяха въведени ограниченията. Всички останали мерки, колкото и нескопосани да са, вероятно са с малко отражение върху крайния резултат.

Въпреки това се случва да се изказвам критично, понякога дори силно критично, към начините на всземане на решения и изпълнението на някои мерки. Например когато се оказа, че решението за затваряне на София е било взето без данни за броя напуснали коли. Или когато въведоха КПП-та с хартиени декларации, които се тъпчат в чували (и после се броят на ръка?). Или когато се появиха опашки пред НОИ за ПИК-ове и всички осъзнаха, че то е-услуги може и да има, но хората няма как да ги ползват. Или когато болници продължават да нямат защитни средства.

Всички тези критики обаче не са към кризисните действие сами по себе си. Кризисните действия не се случват във вакуум, а в контекста на държавното управление. А щабът не е само ген. Мутафчийски (с всички критики и към него), а се състои от доста министри. А мерките изглеждат нескопосани и се прилагат зле, защото просто държавата толкова си може.

Държавата е „прогнила“ и много ключови аспекти не са реформирани с десетилетия. Това личи най-много в кризисни ситуации и води до тази кофти ситуация, в която хем искаме да не сме прекалено взискателни, защото главната цел е да не претоварим здравната система и да не умрем, хем ежедневни глупости ни избождат очите.

Ще дам няколко примера, с които да илюстрирам как неща, несвършени с години, сега поставят под въпрос смисъла и ефективността на някои от мерките:

  • Правосъдие< - видяхме няколко повдигнати обвинения за телевизионни интервюта, видяхме неяснота и несигурност относно декларирането на неверни данни в декларациите за пътуване, видяхме съд, който спря да функционира, защото електронното правосъдие е почти на нулата. Липсата на правосъдие и нереформираната прокуратура са особено опасни в криза, макар това да не се вижда на пръв поглед.
  • Електронно здравеопазване – Националната здравна информационна система трябваше да е готова; в реалността тя не едва е започната. Какво общо има това със справянето с кризата? Да вземем липсата на електронна рецепта. Ако някой иска да получи рецепта по здравна каса, трябва да мине през специалист, РЗОК/НЗОК и личния лекар, като единственото, за което реално има нужда от присъствие, е специалистът. В момента, обаче, пациентът трябва да обикаля болници и опашки, за да получи печати на едни хартии. Това обикаляне повишава риска за него. Електронната рецепта би елиминирала почти всичко това. За обикновени рецепти, в комбинация с коректно регламентирана телемедицина, изобщо няма да се налага да ходите на лекар. Аптеки затваряха, защото бяха подложени на проверки във връзка с Но електронната рецепта е само най-очевидното. Централизираното събиране на данни в структуриран вид и възможността за ефективна комуникация между болници е още по-важна. Вчера беше въведена система за агрегиране на данни от всички лаборатории за резултатите от тестовете за коронавируса. Това не трябваше да отнема два месеца, а вече да го има – единния здравен запис трябва да включва всички прегледи и изследвания на всеки пациент. Събирането на медицинска статистика щеше да става в реално време, а не деловодителки, вадещи числа от епикризи за последния месец.
  • Вземане на решения на база на данни – когато на извънредния брифинг за затваряне на София министърът на вътрешните работи каза, че не знае колко автомобили са напуснали София, придобихме представа за процеса на вземане на решения. Агенция „Пътна инфраструктура“ събира данни от камерите си и може да ги предоставя в реално време. Никой не се е сетил да ги поиска (или по-лошо – сетил се е, но не са му харесали и ги е игнорирал). В даден момент някой беше питал МВР колко акта са съставени за нарушения. Оттам не знаеха. Въпреки, че на сайта coronavirus.bg има данни и от НСИ, и в публикувани в ГИС, суровите данни по дни, области, резултати от тестове, съпътстващи заболявания и т.н. ги няма публично. Притесненията са, че ги няма изобщо. И дори когато ги има, методологията по събирането им не е „както дойде“. И разни истории, разказвани от пациенти и близки на пациенти, навеждат на такава мисъл. „Данни“ не значи числа, прочетени от листче на брифинг.
  • Гражданска регистрация – може би изглежда несвързано, но заради кашата в която се намира гражданската регистрация, държавните органи не знаят кой къде живее. Не могат да му връчат нищо, трябва на декларациите да пише три адреса (постоянен, настоящ, „по местоживеене“). Половината наказателни постановления сигурно ще си останат невръчени или неплатени заради това. Когато кацне самолет отнякъде и гранична полиция не направи нищо по въпроса, след това как се издирва къде живеят всички пътници? А защо това е така? Темата е дълга, но включва анахронизма „постоянен адрес“, както и усложнената процедура по смяна на настоящия адрес и липсата на контрол по въпроса. Ако можеше онлайн да посочиш къде живееш и това влизаше в Национална база данни „Население“, щеше да е чудесно. Вместо това има пълномощни, нотариални актове на собственици и ходене в работно време до общината. Нещо, което почти никой не прави. И нещо, което е оставено да се случва с десетилетия.
  • Електронна идентификация – изведнъж нуждата от електронни услуги се повиши значително. И хората, и администрациите осъзнаха, че всъщност те са неизползваеми. Защото няма как гражданите да се идентифицират онлайн и да подпишат заявленията. Или нямат КЕП/ПИК, или той не им върши работа и за двете стъпки (идентификация и подписване), както съм описал тук. И започнаха едни опашки. Електронната идентификация и стандартизирането на процесите по заявяване се мотае от 3 години и е доникъде. Гражданите продължават да нямат как да ползват електронни услуги, дори когато такива има, и в кризата това създава доста повече проблеми
  • Актосъставяне и контрол – Законът за административните нарушения и наказания е от 60-те. Актосъставянето и изобщо административният контрол са нещо, което плаче за обновяване. Централизирани системи за актовете дори там, където има, рядко позволяват справки по параметри (по кой член е съставен, на каква стойност, обжалван ли е, връчено ли е наказателното постановление и др.). Връчването на последващите наказателни постановления е проблем, плащането – също. Трябваше преди няколко години да се създаде централизирана система за административно-наказателна дейност, но такава все още не е стартирана. В момента МВР е съставило актове за неспазване на мерки, но колко от тях ще бъдат реално платени накрая, не знам. Но предполагам, че не много. Което пък подкопава самата идея на административното наказване – ако знаеш, че може и да не го платиш, си по-склонен да не спазваш ограничения. В същото време органите, с ясното съзнание, че не могат просто да се разходят в парка и да съставят акт на всеки, който не спазва дистанция и се е събрал на поляната да пие бира с още 10 човека, води до пълно затваряне на съответните паркове.
  • Декларации, бележки, печати, вярно с оригинала – наскоро администрацията ми поиска син печат върху банков документ. Бележките от работодател за пътуване трябваше да са с подпис и печат (в началото). Все още всички декларации са само на хартия – няма опция да си попълниш данните онлайн и да минеш през КПП (например чрез автоматична проверка чрез камерите на АПИ) – трябва да спреш и да подадеш хартията на полицая. И така 2 пъти на ден, ако работиш от двата края на КПП. Понякога връщат за липса на нещоси. Кой както си реши на място. За всеки случай. Тази дългогодишна привързаност към хартиените артефакти създава допълнителна нужда от контакт с хора на гише или органи на реда. Което повишава риска за всички. С колко го повишава – вероятно не по-малко, отколкото разходка в парка.
  • Защита на личното пространство – когато в Закона за извънредното положение вкараха възможност МВР да получава данни за местоположението на мобилни телефони без предварителен съдебен контрол, обясних защо на теория това не е толкова страшно. На практика, обаче, Законът за електронните съобщения в частта му за контрола и одитната следа при такъв тип запитвания към мобилните оператори се нуждае от ремонт от много отдавна. Регистри за такива искания се водят често на тетрадки, съответно централизиран контрол (напр. чрез сравняване на записите в правоохранителните органи и тези в мобилните оператори) е доста затруднен. Съдебният контрол пък е всъщност административен и злоупотреби са възможни. Това не е от днес, а отдавна, но точно затова поставя кризисната мярка под въпрос.

Много от ежедневните неудобства, които изпитваме, и които ни карат да не харесваме една или друга мярка, както и системната несигурност, която се прокрадва, всъщност не идват от самата мярка, а от липсата на инфраструктура (нормативна, човешка и техническа) за адекватното им изпълнение. А тази липса е следствие от това, че много системи са нереформирани с години, а много системи, които трябваше да са станали отдавна, се бавят.

На този фон, фактът, че ни се карат от екрана, повишава недоверието. Едно е да видиш добре смазана машина по прилагането на мерките и нарушителите да бъдат мъмрени. Друго е ежедневно да чуваш истории от КПП-тата за върнати бусове със стока, недопуснати до работните си места граждани, километрични задръствания заради подаване на хартийки през прозореца, липса на контрол там, където има значение (например при кацащи самолети от чужбина, при струпвания на хора – дали по празници, дали за да гледат събаряне на сграда). Друго е да виждаш решения, базирани на усещане, а не на данни и хаотични действия, противоречащи помежду си.

Всичко това не е защото не трябва да има мерки срещу вируса. И критиката по-рядко е насочена срещу намеренията на щаба или срещу принципите, на база на които той оперира – а именно, да не позволи загубата на човешки животи. Критиката е срещу дългогодишното корупционно нищоправене, плодовете на което берем сега.

Надявам се въпреки всичко това, да излезем от кризата с минимални щети – както пряко заради вируса, така и непряко, заради икономическите щети. Това е трудна задача и никой няма стопроцентов отговор. Не очаквам и да има. Но много ще помогне, ако може се разчита на „системата“. И ако за тази криза вече е късно, то за следващата трябва тази система да е по-малко прогнила.

Затова и всичките ми публикации досега са били конструктивни – как да ползваме електронните услуги, какви мерки могат да бъдат взети в бърз порядък, за подобряване на ситуацията. И помагам с каквото мога, където мога. Конструктивността е важна в такива ситуации. Но проблемите също трябва да бъдат маркирани, защото иначе може да не си научим урока за следващия път.

AWS Alarms for Application Errors

Post Syndicated from Bozho original https://techblog.bozho.net/aws-alarms-for-application-errors/

Monitoring is key for any real-world application. You have to know what’s happening and be alerted in real time if something wrong is happening. AWS has CloudWatch for that, and gives you a lot of metrics automatically. But there are some that you have to define yourself. And then you need to define proper alarms.

Here I’ll focus on hour:

  • High number of application errors
  • High number of application warnings
  • High number of 5xx errors on the load balancer
  • High number of 4xx errors on the load balancer

First, the prerequisites:

  • You need to be using CloudFormation to automate everything. You can create all of those things manually, but automation is a big plus
  • If using CloudFormation, you’d preferably have a sub-stack for configuring alarms
  • You need to be collecting your logs with CloudWatch logs

If you are not using CloudWatch logs, here’s a simple config file and script to enable them:

{
  "agent": {
    "metrics_collection_interval": 10,
    "region": "eu-west-1",
    "logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "{{logPath}}",
            "log_group_name": "{{logGroupName}}",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%Y-%m-%d %H:%M:%S"
          }
        ]
      }
    }
  }
}
# install AWS CloudWatch monitor
mkdir cloud-watch-agent
cd cloud-watch-agent
wget https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip
unzip AmazonCloudWatchAgent.zip
./install.sh

aws s3 cp s3://$BUCKET_NAME/cloudwatch-agent-config.json /var/config/cloudwatch-agent-config.json
sed -i -- 's|{{logPath}}|/var/log/application.log|g' /var/config/cloudwatch-agent-config.json
sed -i -- 's|{{logGroupName}}|app_node|g' /var/config/cloudwatch-agent-config.json

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/var/config/cloudwatch-agent-config.json -s

Now you have to define two things: Log metrics and alarms. The cloudformation code below creates both:

    "HighAppErrorsNotification": {
      "Type": "AWS::CloudWatch::Alarm",
      "Properties": {
        "AlarmActions": [
          {
            "Ref": "NotificationTopicId"
          }
        ],
        "InsufficientDataActions": [
          {
            "Ref": "NotificationTopicId"
          }
        ],
        "AlarmDescription": "Notify if there are too many application errors",
        "ComparisonOperator": "GreaterThanOrEqualToThreshold",
        "EvaluationPeriods": "1",
        "MetricName": "ApplicationErrors",
        "Namespace": "LogMetrics",
        "Period": "900",
        "Statistic": "Sum",
        "Threshold": "5",
        "TreatMissingData": "ignore"
      }
    },
    "ErrorMetricFilter": {
      "Type": "AWS::Logs::MetricFilter",
      "Properties": {
        "LogGroupName": "app_node",
        "FilterPattern": "ERROR",
        "MetricTransformations": [
          {
            "DefaultValue": 0,
            "MetricValue": "1",
            "MetricNamespace": "LogMetrics",
            "MetricName": "ApplicationErrors"
          }
        ]
      }
    },

If you need to do that manually, go to the CloudWatch logs homepage, select the log group (app_node) and use the button “Create metric filter” ontop. It lets you specify the pattern to look for (“ERROR” in this case). When you have that ready, you can create an Alarm based on it, through the Alarms -> Create alarm. Lookup the metric by name and select it to trigger the alarm (in the example above, it gets triggered if there are more than 5 errors within 900 seconds)

You can then create an identical alarm for warnings (pattern to look for: “WARN”). The threshold there might be higher, e.g. 10 or 20. But that depends on your application logging patterns.

Then there’s the error 5xx load balancer alarms. In CloudFormation it would look like this:

   "TooMany5xxErrorsWebAppAlarmNotification": {
      "Type": "AWS::CloudWatch::Alarm",
      "Properties": {
        "AlarmActions": [
          {
            "Ref": "NotificationTopicId"
          }
        ],
        "InsufficientDataActions": [
          {
            "Ref": "NotificationTopicId"
          }
        ],
        "AlarmDescription": "Notify if there are too many 5xx errors",
        "ComparisonOperator": "GreaterThanOrEqualToThreshold",
        "Dimensions": [
          {
            "Name": "LoadBalancer",
            "Value": {
              "Ref": "WebAppALBId"
            }
          }
        ],
        "TreatMissingData": "notBreaching",
        "EvaluationPeriods": "1",
        "MetricName": "HTTPCode_Target_5XX_Count",
        "Namespace": "AWS/ApplicationELB",
        "Period": "60",
        "Statistic": "Sum",
        "Threshold": "2"
      }
    }

You can again create that manually – look for the HTTPCode_Target_5XX_Count metric in the metric selection screen for the alarm. You have several options there, the most straightforward is to select the per AppELB metric. And again, the same approach can be used for 4xx errors (HTTPCode_Target_5XX_Count).

Getting this running with CloudFormation (and even manually) is not as straighforward as it seems. The right combination of metric names, namespaces and values is not obvious and the relevant documentation is not the first thing that pops up. So I decided to share something that works, as it may take some time experimenting before getting it to that state.

But even outside of CloudFormation or AWS context, monitoring and alerting in case of a high number of application errors, warnings and HTTP errors is a must. And automating the creation of those alarms is the recommended approach.

The post AWS Alarms for Application Errors appeared first on Bozho's tech blog.

Как да ползваме електронни услуги

Post Syndicated from Bozho original https://blog.bozho.net/blog/3536

Поради мерките за справяне с пандемията с право хората избягват да се редят на опашки в институции. Държавата и общините, обаче, не са готови са посрещнат търсенето за електронни услуги. По ред причини, на които няма да се спирам сега. Реших да синтезирам дългогодишния си опит в „тролене“ на администрацията с опитите си да получа всяка услуга по електронен път от край до край (ниво 4). Съветите долу са законосъобразни спрямо моето разбиране на Закона за електоронното управление и Административнопроцесуалния кодекс. Много юристи в много администрации няма да са съгласни с това разбиране. Затова е и точка 7. Нямам претенции за изчерпателност и със сигурност ще пропусна нещо, но мисля, че за начало е достатъчно.

Този „наръчник“ се надявам да е полезен както на хората, които искат да заявяват услуги, така и на администрациите, които не са свикнали да ги получават по електронен път и не знаят кое може и кое не може. Фокусиран е малко повече върху физически лица, но важи в същата сила и за юридически. Там единствената особеност е, че някои администрации могат да искат КЕП на юридическо лице (какъвто не съществува в правния мир, но това не пречи на никого да го изисква).

1. Идентификация

Национална eID схема все още няма, но имаме една пъстра мозайка от опции. Идентификацията е първата стъпка – как влизате в съответната система. В зависимост от всяка от опциите, последващите варианти за подписване (което също се изисква, за да заявите услугата) са различни.

  1. Квалифициран електронен подпис „на флашка“ (смарткарта) – такъв можете да получите от офис на доставчик на удостоверителни услуги – Борика, Информационно обслужване, Инфонотари, СЕП. С такъв КЕП можете да се идентифицирате в повечето системи на администрацията, но изисква инсталиране на драйвери, специален софтуер, Java, а често работи само на стари браузъри (Internet explorer 8) или Firefox ESR. КЕП струва пари, но не е особено скъп.
  2. Облачен квалифициран електронен подпис – такъв предлагат Евротръст и Борика-Банксервиз. Евротръст може да ви го издаде отдалечено, чрез видеоидентификация в приложението, а Борика изисква да сте имали преди това техен подпис, за да си издадете мобилен. С такъв КЕП можете да се идентифицирате само за услуги, които изрично са се интегрирали с доставчиците или със системата за електронна автентикация на ДАЕУ, което е интегрирана и с двете. Системата за електронно връчване и системата за електронни форми са интегрирани със системата за електронна автентикация (ще видим след малко, че това върши работа в много от случаите)
  3. ПИК на НАП – с ПИК на НАП може да се идентифицирате само в НАП и за услуги на администрации, които са интегрирани с НАП. Това са някои общини и НОИ (вероятно има и други, не ги знам наизуст и няма списък с тях). След идентификацията, обаче, можете да подписвате само пред НАП. Т.е. на друми места ви дава само справочна функционалност.
  4. ПИК на НОИ – с ПИК на НОИ можете да се идентифицирате в НОИ и в системата за електронна автентикация, т.е. имате достъп до е-връчване и е-форми.
  5. ПИК на община – някои общини издават свой ПИК. С него имате достъп само до системите им за общински услуги
  6. Свободен достъп – съществуват услуги със свободен достъп (най-много да изискват регистрация с имейл). Те са най-често справочни. Върху тях няма да се фокусирам, но има немалко такива, които се отнасят до публични данни – на кадастъра, на имотния регистър, и др.

2. Системи за е-услуги

Електронни услуги могат да се заявяват по различни канали. По принцип могат и по електронна поща, но това е в краен случай. Иначе вариантите са:

  1. Система за е-услуги на съответната администрация – влизате в сайта на администрацията и търсите „Е-услуги“ или „Електронни услуги“. Повечето общини имат такива. В сайта на Столична община са сравнително трудно откриваеми, затова ето линк. На други места може да пише, че има е-услуги, но те всъщност да не работят. Тези услуги можете да ползвате обикновено само с КЕП „на флашка“ или с ПИК на община. Централните администрации също имат е-услуги, и при тях все още интеграция със системата за е-автентикация на практика няма, така че опциите са КЕП.
  2. Система за сигурно електронно връчване – оттук можете да връчите всичко на всяка администрация в списъка (а почти всяка е включена). Връчването може да се ползва за заявяване на услуга, ако приложите съответното заявление за услугата и необходимите придружаващи документи. Бланката за заявяване можете да намерите на сайта на съответната администрация при добро желание и време за ровене
  3. Електронни форми – това е система, базирана на системата за електронно връчване, при която бланките за заявяване на множество услуги са електронизирани в PDF формат, така че да можете да ги попълните и подпишете електронно

3. Подписване

Подписването е най-специфичният момент. Той е и най-важният за администрацията – нещо няма ли подпис, все едно не е подадено. Има различни философски виждания по темата, но нека сме практични – ако няма подпис, просто ще ви върнат. Така че вариантите са следните:

  1. Подписване с КЕП в система за е-услуги – това е най-неудобното, заради нуждата от стари браузъри и Java. Някои администрации (като НАП) имат по-съвременно решение, но повечето системи не го ползват и съответно мъката всичко да тръгне е голяма.
  2. Подписване с КЕП в на локалния компютър – всеки PDF и Doc файл може да бъде подписан с КЕП. Word позволява това чрез опцията „Add signature line“, а Adobe reader – с Tools -> Certificates -> Digitally sign. Електронните PDF форми на системата за е-форми автоматично извиква диалога за подписване при натискане на съответната кутийка.
  3. Подписване с облачен КЕП – свален документ може да бъде подписан с облачен КЕП през портала на съответния доставчик. Съответно portal.evrotrust.com и my.b-trust.bg. Услугите са интуитивни и поставят електронния подпис след следване на инструкциите.
  4. Подписване с ПИК – това е възможно само на сайта на НАП за целите на техните услуги.
  5. Подписване на хартия и пращане през е-връчване – има възможност да разпечатате (попълнена) бланка, да я подпишете на хартия, да я сканирате (или снимате с телефон) и да я пратите така, през електронното връчване. Тази опция е нежелателна, защото изпратеното не е оригинал и може да ви върнат. Има правна логика да приемат приемат заявлението, но няма да навлизам в нея. В ситуация на извънредно положение може и да бъде допуснато по-леко. Може на някой да му хрумне да напишете „Вярно с оригинала“ на така сканираното заявление.

4. Необходими документи

Необходимите документи, които се прилагат към заявлението, могат да бъдат:

  1. Удостоверения и други документи, доказващи някакво обстоятелство – по принцип тези не би трябвало да бъдат изисквани, а администрацията да си ги събере по служебен път. Но битката кое може да искат и кое не е дълга и е различна с всеки, така че може да си я спестите, като прикачите съответните документи, които съответно сте получили с отделно заявление.
  2. Декларации – намират бланка или пишете декларация в свободен текст и я прикачате, подписана по някой от горните начини
  3. Други придружаващи документи – същото важи и за тях – подписани по някой от горните начини (в краен случай на ръка и сканирани) и прикачени към заявлението. Ако системата позволява прикачане само на един файл, правите zip архив.
  4. Документи за платена такса – това по принцип не трябва да го изискват, но го изискват. Таксите могат да се плащат по банков път (банковите сметки на институциите ги има по сайтовете), като може да ги платите през електронното си банкиране и да приложите screenshot от платежното, генерирано в е-банкирането. Някои услуги поддържат и плащане с карта – там няма нужда да се прикача платежно.

5. Плащане

Често услугите изискват плащане. Тази стъпка се интегрира трудно в неструктуриран процес по заявяване, така че отново възможностите са няколко. По принцип прикачването на платежни не е нужно, защото те могат да видят, че именно от вас са получили превод в справката от банката си, но както писах и по-горе – изискват го. Така че ето опциите:

  1. Плащане с банкова карта чрез платежен оператор – някои услуги са интегрирани я с БОРИКА директно, я с ePay, я със системата за електронни плащания на Държавна агенция „Електронно управление“. При плащане с карта е лесно, а администрацията получава потвърждение автоматично
  2. Плащане по банков път с електронно банкиране – когато няма интеграция с платежна система, на сайта на администрацията има банковите ѝ сметки. Ако не са видими, може да потърсите в Гугъл „<Име на администрация> IBAN“. Електронните банкирания имат отделен интерфейс за преводи към бюджета, с малко по-сложни форми. В някои случаи административните услуги изискват определен код за плащане, което не е интуитивно и трябва да се намери на сайта. Може да звъннете в съответната администрация, за да питате за кода за съответната услуга, ще ви го кажат. След това електронните банкирания позволяват експорт на платежните за печат – избирате „Print to PDF“ и прикачате получения PDF към услугата. Ако няма такава опция, може да приложите и Screenshot (Клавиш Print screen -> Paste в Paint)
  3. Плащане по банков път на гише – когато нямате е-банкиране или пък имате клон на банка наблизо, може да платите и на гише. След това сканирате платежното (или го снимате със смартфон) и го прикачвате към заявлението.</ли>

6. Получаване

Получаването е важен момент. Трябва да искате получаване също по електронен път. В редки случаи това не е приложимо (например лична карта или паспорт), но в повечето случаи електронен документ върши работа. В краен случай може да получите документа (резултат от услугата) по пощата. Много администрации ще приемат заявлението, но вътрешният им процес е на хартия и ще държат да ви пратят подпечатан оригинал.

7. Нормативни основания

Понякога при заявяване ще ви откажат предоставяне, защото „не може по електронен път“. Или „не може по този начин“. Или „изисква се лично явяване“. Или „това не е истински подпис“. Или „трябва да има печат“. Или някоя друга глупост. Надявам се да не стигате до това, защото тогава вероятно ще се откажете и ще отидете на гише, но все пак ето няколко члена, които да цитирате в разговор с администрацията:

  • Закон за електронното управление: Чл. 11. Доставчиците на електронни административни услуги не могат да отказват приемането на електронни документи, изявления, издадени и подписани като електронни документи съгласно изискванията на закона, както и да отказват издаването на електронни документи.
  • Закон за електронното управление: Чл. 19. Получателите на електронни административни услуги могат да извършват електронни изявления и да ги изпращат по електронен път при спазване на изискванията, определени със закон.
  • Закон за електронното управление: Чл. 25. (1) Получателят на електронната административна услуга е длъжен да приема електронните изявления от доставчика за потвърждаване на получаването и за резултата от проверката на редовността на подадените документи.
  • Закон за електронното управление: Чл. 26. (5) Подаването и връчването на документи по електронен път, свързано с предоставянето на електронни административни услуги, се осъществява и чрез система за сигурно електронно връчване, поддържана от Държавна агенция „Електронно управление“.
  • Административнопроцесуален кодекс: Чл. 18а. (2) Административните органи, органите на съдебната власт, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги, осигуряват техническата възможност исканията, сигналите и предложенията, жалбите, протестите, молбите, исковете и приложенията към тях да се подават по електронен път по реда на Закона за електронното управление в производствата пред административен орган или съответно по електронен път по реда на Закона за съдебната власт в производствата пред съд.
  • Административнопроцесуален кодекс: Чл 13а. Административните органи прилагат комплексно административно обслужване (обслужване, при което административната услуга се извършва от административни органи, от лица, осъществяващи публични функции, или от организации, предоставящи обществени услуги, без да е необходимо заявителят да предоставя информация или доказателствени средства, за които са налице данни, събирани или създавани от извършващия административната услуга първичен администратор на данни, независимо дали тези данни се поддържат в електронна форма или на хартиен носител.)
  • Регламент (ЕС) 910/2014: Чл. 12, 2. Правната сила на квалифицирания електронен подпис е равностойна на тази на саморъчния подпис.
  • Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги: Чл. 20. (3) При липса на информационна система за приемане на заявление за определена административна услуга се допуска електронно заявяване чрез попълване на електронен документ с неструктурирано съдържание във формат по чл. 36 и изпращането му на електронната поща на доставчика на административни услуги.

При отказ, в краен случай може да им казвате, че подлежат на глоба между 500 и 1500 лева и че подавате сигнал до Държавна агенция „Електронно управление“. Глоба едва ли ще има (никой досега не е налагал глоби по тоя закон, сакън), но сигнал до ДАЕУ е добра идея (на [email protected]).

8. Обобщение

Информацията, описана горе е доста и бих искал да представя нагледно в табличен вид:

ИдентификацияПодписванеПлащане
Система за е-услуги на отделна администрацияКЕП, в някои случаи ПИККЕП, ПИК (само за услуги на НАП)С карта, по банков път
Система за сигурно електронно връчванеКЕП, Облачен КЕП, ПИК на НОИКЕП, Облачен КЕП, ръчноПо банков път
Система за електронни формиКЕП, Облачен КЕП, ПИК на НОИКЕП, ОБлачен КЕПС карта (pay.egov.bg)

9. Заключение

Има много варианти за заявяване на услуги, в зависимост от обстоятелствата (с какво средство за идентификация и подписване разполагате, можете ли и искате ли да се разходите до някой офис или не, какво предоставя администрацията). Никой не е напълно удобен и интуитивен, поради което се използват рядко. В случай, че горното описание не е достатъчно, винаги може да се обадите на контактния център на ДАЕУ (ако ползвате е-връчване или е-форми), за да ви помогнат.

Бих посъветвал администрациите на сайтовете си да разпишат в прости стъпки, дори с картинки, как се ползват техните услуги, евентуално в структурата, която съм ползвал.

Електронното управление е в този си вид, защото няма достатъчно търсене за него. Когато на никой не му и хрумва да провери има ли електронна услуга за нещо (защото няма как да я ползва, например), е нормално нещата да са неудобни и „забутани“. Ще цитирам клишето, че всяка криза е и шанс. В случая – шанс електронното управление да заработи по-активно и по-добре.

Am I a Real Expert?

Post Syndicated from Bozho original https://techblog.bozho.net/am-i-a-real-expert/

The other day I had a conversation with a scientist friend who said something alone the lines of “yes, I work in that general field, but I’m not an expert in your question in particular”. IT is not science, of course, but I asked myself whether I am a real expert in the things that I do. And while it’s nearly impossible to hit exactly the fine line between impostor syndrome and boasting, this post is neither and has a point, so bear with me.

I’ve been doing a lot of things in the general IT field – from general purpose software engineering, IT architecture, information security, applications of cryptography, blockchain, e-government, algorithmic music composition, data analysis. And I’ve seen myself as having relatively expert knowledge. I even occasionally give TV and radio interviews, where I’m labelled as “Expert in X”. But…

  • Am I a real expert in software engineering and software architecture? I’ve been doing that for 15+ years, and I follow and somethings define or clarify best practices, I’m familiar with different methodologies and have been part of teams that implemented some of them correctly and efficiently. I have taken part in the decision making process of building large systems with their architectural implications. But I’ve never been formally assigned as an “architect” (not that I insist), my UML skills are rather basic and I’ve never had to integrate dozens of legacy systems. I’ve never used formal methods for assessing software, I’ve made mistakes in selecting technologies, I’ve never done proper TDD and I have only a basic understanding of networking. Maybe just the sheer amount of years of experience positions me as an expert, maybe the variety of projects I’ve worked on.
  • Am I a real expert in cryptography? Almost certainly not. Yes, I’m using cryptographic building blocks regularly, I know what an initialization vector is and I’ve code reviewed a merkle tree implementation. I’ve read dozens of papers on cryptography and understood many of them. But some papers are greek to me – I have no clue about the math behind cryptography. Sure, RSA is easy, but I have just a basic understanding of how elliptic curves work. On the other hand, I probably know more than 99% of the software industry, where the average person barely differentiates symmetric and asymmetric cryptography, IV is a roman numeral, and cryptography boils down to disabling TLS 1.0 on a web server.
  • Am I a real expert in information security? I’ve given talks on it, I’m in the infosec business, I know and follow best security practices, I know about sqlmap and I’ve even used Wireshark; I understand DEFCON talks and I’ve even decompiled several apps to find (and report) security vulnerabilities. But I’m no Mr. Robot-level hacker, nor I’m a CISO in a large organization who has to plan and implement security measures on hundreds of systems. I haven’t been part of red-teaming exercises and I haven’t built or operated a security operations center (SOC). But maybe in an industry where even having heard of OWASP puts you in the top 10% and actively thinking about the security aspects of each new piece of code puts you in the top 1%, I’m an expert.
  • Am I a real blockchain expert? I know Bitcoin’s and Ethereum’s implementations, I have implemented something similar to bitcoin’s data structures, I know what a Patricia merkle tree is and I’ve built and pushed raw Ethereum transactions. But I’m no Vitalik Buterin, I can’t build something like Ethereum, I’m only vaguely familiar with distributed consensus algorithms and their pitfalls, and I haven’t written a smart contract more complicated than a tutorial example. I haven’t run a production deployment of Hyperledger (only a test one), and I largely ignore most of the new networks. You may say that one doesn’t need to be Vitalik or Satoshi to be an expert, and with most people seeing blockchain as “that thing that stores data in an unmodifiable way”, one could be an expert by just writing a Hello world smart contract.
  • Am I a real e-government expert? Sure, I’ve been an e-government advisor to a deputy prime minister, I’ve co-authored legislation and strategic documents and understand how and why e-government works in several EU countries, most notably Estonia, but do I have a holistic view? I have almost no idea of how the e-government is structured in South Korea, Singapore or UAE, for example, I haven’t written a single paper, and I haven’t measured the impact of legislative, organizational and technical measures that we proposed and applied. There are questions that I don’t know the answer to – e.g. how to make the pan-European eID framework actually work.

So the question is – what does it mean to be an expert anyway? We will always be somewhere on an “expert spectrum”. And in many cases our industry doesn’t apply even basic good practices, so even basic expertise can be very valuable. There are always people that know more than you on a given sub-sub-field, and there are always people that are better than you at most of the things that you do. The reputation of “expert” is something important, yet something so vague. Individually it’s good to know where one stands (Dunning-Kruger and everything), and to be aware of the limits of one’s knowledge and understanding. Knowing the things that you don’t know is a good start.

But in a broader context, who’s an expert? Imagine that after we recover from the COVID-19 crisis, there’s a cyber crisis. Who will be the IT experts to advise governments on the measures to be taken? University professors? Senior silicon valley technical people? Who will be on TV to discuss the cyber crisis in the role of “expert” – a senior engineer at a big bank, a junior developer, or someone that took CS 101 in university and happens to know the host? Who will drive the agenda and public opinion?

The level of our expertise is primary for our careers, but it also has other aspects outside of our immediate field. When a crisis hits (and even if it doesn’t) it’s important that we have real experts, that we listen to them and that we trust them. But also to realize no expert knows everything about everything, and that many questions don’t have absolute answers, even for experts. That knowledge decays if not utilized and “published a paper 30 years ago” may be irrelevant today.

I promised that the article would have a point. And it’s two-fold. First, make sure you know what you don’t know, so that you can explore it if needed. Second, we need to value expertise with its imperfections. There is no absolute expert in anything, there are only relative experts. And forgive me for going through my skills (or lack thereof), but that was the best way I could think of for illustrating my point in depth.

Finally, I hope there isn’t a global IT-related crisis. But as some consider it inevitable, we may think about the perception of expertise in our field and who can we trust with certain aspects. There is no “full stack” expert, as the field is too broad.

The post Am I a Real Expert? appeared first on Bozho's tech blog.

Земетресението в Лисабон, Великден и коронавирусът

Post Syndicated from Bozho original https://blog.bozho.net/blog/3532

През 1755 г. Лисабон е ударен от много силно земетресение – 8.5-9 по скалата на Рихтер.

Земетресението е на 1-ви ноември, денят на вси светии, поради което много хора са в църквите и палят свещи. Свещи се палят и по домовете, за празника.

Заради свещите, градът пламва и ако нещо е останало здраво от силното земетресение, то изгаря.

Хората излизат от църквите и къщите и се струпват на открито пространство в града. За съжаление, епицентърът е в Атлантическия океан и скоро градът е залят от цунами.

Иронията е, че на религиозния празник всичко е опустошено, а кварталът с „червените фенери“ има най-малко щети (просто е на хълм с по-здрави скали).

Земетресението, случило се точно на релгиозния празник, дава тласък на т.нар. теодицея – философското търсене на причините защо Бог позволява да се случват лоши неща (или защо ги предизвиква). Защо въпреки, че жителите на Лисабон са почели светиите, точно на този ден е дошло Божието наказание.

Това дълго въведение е във връзка с предстоящия Великден и рискът от струпване на хора в църквите в ситуация на епидедмия.

Жителите на Лисабон не са знаели, че ги очаква земетресение. Но ние знаем, че струпването на хора носи висок риск от разпространение на вируса.

И всички вярващи, които смятат, че вярата им е достатъчна, за да не се заразят – теодицеята е израз на това, че колкото и да вярваме, лоши неща се случват. Можем да търсим философско обяснение за това, но на първо място трябва да вземем всички земни мерки, които можем, за да ограничим щетите – за себе си и за близките ни.

Целуването на икони и струпването в църквите е опасно. А както и земетресението в Лисабон, заразата няма да ни се размине, само защото сме силно вярващи.

Ще ни подслушва ли МВР през трафичните данни?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3521

Със Закона за извънредното положение депутатите дадоха право на МВР да получава трафични данни без предварителен съдебен контрол за лица, които са нарушили принудителна карантина, наложена от Министъра на здравеопазването, във връзка с вируса. Това предизвика доста реакции и свръхреакции и предупреждения, че с тези правомощия ще започне едно „безконтролно подслушване“. Ще опитам да направя няколко кратки уточнения и след това да опитам да обясня защо въпреки, че злоупотреби са много малко вероятни, текстът в закона е лош.

Не, МВР няма да ни подслушва. В трафичните данни не влизат данни за самите разговори и съобщения, така че това е технически невъзможно. Влизат метаданни – с кого сме говорили, кога, колко дълго, както и към кои клетки сме били вързани, т.е. приблизително какво ни е било местоположението. Ако трябва да сме прецизни, последното не са трафични данни, а данни за местоположение, но и те влизат в обхвата на Закона за електронните съобщения (ЗЕС):

1. проследяване и идентифициране на източника на връзката;
2. идентифициране на направлението на връзката;
3. идентифициране на датата, часа и продължителността на връзката;
4. идентифициране на типа на връзката;
5. идентифициране на крайното електронно съобщително устройство на потребителя или на това, което се представя за негово крайно устройство;
6. установяване на идентификатор на ползваните клетки.

Конкретната мярка, обаче, се отнася само до точка 6 – използваните клетки. Т.е. само проследяване на придвижване.

Не, МВР няма да го прави безконтролно – мярката е предвидена само за случаите, в които е нарушена принудителна карантина. Законът не дава право да се искат данни в други случаи. Това е на теория, на практика ще видим след малко. И не, мярката не е противоконституционна (поне на пръв поглед от човек без опит в тълкуване на конституционни норми), защото в извънредно положение някои конституционни гаранции, вкл. това на неприкосновеност на комуникацията и за защита от следене, отпадат.

Мярката важи само до изтичане на извънредното положение. Но депутатите са искали точно този параграф да важи и по-дълго (до отпадане на нуждата от принудителна карантина). Може би от техническо недоглеждане, а може би нарочно, мярката е по чл. 61 изобщо, т.е. мярката ще остане в сила заради други болести, при които може да се налага карантина. Така че на практика мярката не е временна.

Аз лично смятам, че целта на измененията е приемлива – имаме вече случаи на лица, които са избягали и които са били заразени и това не е окей. Утре ще се качат в автобуса и ще заразят всички.

Смятам обаче, че текстовете не са добри (да не каже мърляви) и създават рискове за злоупотреби. В по-широк контекст, Законът за електронните съобщения има дефицити, които трябва да бъдат поправени не само за рамките на извънредното положение, а по принцип. Никога нещата не са чернобели – никой няма да въведе „безконтролно подслушване“, но това не значи, че определени политически фактори не искат да имат вратичка за набавяне на информация за свои опоненти. И затова задачата по формулиране на тези текстове е трудна.

Дотук добре. Следя измененията (и опитите за такива) в Закона за електронните съобщения отдавна и при тях винаги има конфликт между желанието на органите на реда по-свободно да придобиват информация и желанието на гражданите това да не се случва. Оперативно работещите по престъпления полицаи реално имат нужда от такива данни, за да си свършат работата. Но рядко вземат предвид рисковете, които нормативната уредба създава.

Законът има дълга история, която включва и една отменена европейска директива, но най-важното и интересно – решение на Конституционния съд, което отменя предишни текстове, които въвеждат събирането и достъпа до трафични (и свързани с тях) данни. Решението си струва да се прочете в цялост, защото до голяма степен аргументите важат и за действащите текстове на закона. Цитирам един от най-важните абзаци:

Въведеният с оспорените разпоредби на ЗЕС режим на запазване на данните от телекомуникационния трафик страда от редица други несъвършенства и пороци, които също се оказват несъвместими с конституционната граница на допустимата намеса в сферата на основните права. За да бъде оправдана, нейната материалноправна и процесуалноправна уредба трябва да съдържа ясни, точни и недвусмислени основания и процедури, които да осигуряват достатъчно сериозни и надеждни гаранции, че достъпът на съответните национални органи до запазените данни ще бъде използван само за целите на предотвратяването и разкриването на тежки престъпления и ще обслужва единствено наказателните производства, водени за такива престъпления. Казано с други думи, правната уредба трябва да създава и гарантира сигурност у гражданите, че са изключени всякакви злоупотреби с техните данни както от страна на държавните органи, на които е осигурен достъп до тях, така от търговските дружества (предприятията), предоставящи съответните съобщителни мрежи и услуги, които всъщност ги съхраняват.

И нещо, което на няколко пъти съм предлагал:

На следващо място е необходимо да се констатира, че изобщо липсва уредена със закона правна възможност, а оттам и основания и процедура засегнатите от мерките лица, чиито данни са били предоставени на съответните държавни органи, но не са послужили за образуване на наказателно производство или образуваното е било прекратено, да бъдат уведомени за това кога и на какво основание са били обект на тяхното приложение, както и за какво са били използвани.

От моят гледна точка, и в пълно съгласие с мнението на Конституционния съд, както в действащите текстове, така и в новоприетите, имат два дефицита:

  • Законови гаранции за спазването на процеса – в момента пише, че се води регистър на исканията за трафични данни. В зависимост от това за коя институция става дума, той може да е на тетрадки пръснати из страната (а достъп имат не само МВР – и ДАНС, и прокуратура, и др. Уточнявам, че конкретно за карантината достъп има само МВР, а в другите случаи). Липсва и делегация към наредба, с която да се установи реда за водене на документацията. В т. 2.2 от този доклад (от 2015 г) виждаме, че почти всичко се води „на хартиен носител“ (което значи „тетрадка“). Проследимостта на процеса е много важна и възможността някой да забърше лист от тетрадката или да мине с коректор или изобщо да не впише нещо съществува. Да, в МВР конкретно със заповед на министъра е уреден по-адекватен ред, но това не следва по никакъв начин от закона и както се е появило, може утре да отпадне.
  • Липса на ред за уведомяване – в случаите, когато използваните данни не са довели до повдигнато обвинение, човек не разбира изобщо, че са искали данни за него. А особено в случай на карантина, това е важна защитна мярка. Особено ако се направи умно и може да бъде направена проверка и в мобилния оператор (който също трябва да съхранява някаква документация по въпроса).

„Ама какво толкова може да стане, нали имат процедури“. Да, никой няма да тръгне да ви гледа кога сте ходили на магазина и кога сте говорили с майка си по телефона. Едва ли ще има и мащабни злоупотреби. Само че когато липсват и нормативни, а и технически гаранции, остава да разчитаме на едни вътрешни процеси и на хората, които ги изпълняват. И си представете как утре един министър на вътрешните работи или пък главен прокурор решава, че някой много го дразни и иска да намери нещо, за което да го „хване“ (буквално и преносно). Може или да промени заповедта, която установява сегашния режим, или просто да нареди устно на някого да поиска данни без да ги вписва никъде. Или да впише грешно основание. И да го замаже в тетрадката, за да е нечетливо. И след това няма проверка на документи назад във времето. Или точно за проверката на тези документи някой е пратен в командировка. И други хипотези, звучащи малко вероятни, но възможни.

Онзи ден четох пример за прането пари – в САЩ банките трябва да изпращат до държавата доклад за съмнителни транзакции. И банките са дефинирали такъв вътрешен процес, но служители, участващи в прането на пари, подготвят документите, вкарват копието за банката в архива, а копито за държавата – в коша.

Процесите се изпълняват от хора, а хората имат началници, страхове, слабости. В ситуация на млада демокрация, след тоталитарен режим, без изградени традиции, изкушенията за злоупотреби с най-разнообразни цели, в т.ч. политически, не са малки. Помним делото „Червей“ само от преди няколко години. И ще е грешно да се доверим сляпо на вътрешни процеси в МВР, прокуратурата и службите, които дори не са скрепени с нормативни текстове. Особено когато част от тези институции напоследък демонстрират непризнаване на принципите на правото.

Последният щрих на законодателната немарливост е че новите текстове са сложени в члена, който се отнася за тежките престъпления. Нарушаването на карантината не е тежко престъпление (макар че за малко да го превърнат в такова с увеличаване на наказанията в Наказателния кодекс). Да, режимът на достъп без предварителен съдебен контрол е по този член. Но е въпрос на добра законодателна техника да не смесваш тежки престъпления с нарушаване на карантина, дори режимът да е същият – по-добре би било да има нов член, който препраща към режима по съществуващия.

В заключение – целите на мярката са разбираеми и приемливи. В краткия период е малко вероятно (но не изключено) някой да злоупотреби. За щастие прокуратурата няма достъп до тази процедура, а само МВР. Но дефицитите на самия закон допускат злоупотреби и всяко разширяване на правомощията автоматично страда от тези дефицити. Извънредното законодателство не е нещо, което трябва просто да мине, защото е извънредно – трябва да бъде прецизно. Настоящият състав на Народното събрание за съжаление няма това разбиране на кохерентност на правната рамка и поради това предизвиква скандали. Скандали, които се увеличават допълнително заради липсата на доверие в институциите.

Automating the Change of WordPress Permalinks

Post Syndicated from Bozho original https://techblog.bozho.net/automating-the-change-of-wordpress-permalinks/

WordPress is powering 35% of website. And while it may not be seen as very complex or interesting, it is one of the most prevalent technologies of our time. And many developers, even if they are not working with PHP, have to support some WordPress installation (e.g. a blog like this one). And unfortunately, there are still basic things that you can’t easily do. Plugins do help, but they don’t always have the proper functionality.

Today I had to change permalinks on a website. From https://example.com/post-name to https://example.com/blog/post-name. And WordPress allows that, except there’s a problem – when you change it, the old links stop working (404). Not only that ruins your SEO, any previous share of your post will not work. I’ve pointed that out a long time ago when Spring broke their documentation links. Bottomline: you don’t want that to happen.

Instead, you want to do 301 redirect (and not 302, which appears to also break your SEO). But all tutorials that are easily found online assume you can manually configure redirection through some plugin. But if you have 100-200 posts, that’s a lot of tedious work. There are plugins that allegedly monitor your posts for changes and create the redirects automatically. That may work if you manually edit a post, but it didn’t work for me when changing the permalink format settings.

So how to do it in an automated way and without disrupting your website? You’d need a little bit more than a plugin – namely SQL and Regex. Here are the steps:

  1. Install and activate the Redirection plugin
  2. Open your blog’s hosting admin page and navigate to the PhpMyAdmin to browse your MySQL database. That’s the typical setup. If you are using another database admin tool, you’ll know what to do
  3. Run a query to fetch the post name of all published posts: SELECT post_name FROM `wpgk_posts` where post_type = "post" and post_status = "publish" LIMIT 200 (if you have more than 200 posts, increase the limit; if you don’t put a limit, PhpMyAdmin puts a default one)
  4. Expand the retrieved text (with the big T), select all records with the checkbox below and click “Copy to keyboard”
  5. Paste in Notepad++ (or any regex-supporting text editor, or if you are running Linux, just create a file and then you’ll be able to do regex replaces wit sed)
  6. Replace all tabs that you may have copied (\t)
  7. Then replace (.+) with /$1/,/blog/$1/ (if you are redirecting /postname to /blog/postname, otherwise you have to write the appropriate regex)
  8. Change the permalink format settings
  9. Import the resulting CSV file in the Redirection plugin. It interprets it as: source,target. That way you have redirected all your existing posts to their new permalink (the redirects are created in the chosen group). Note the trailing slash. Just in case, you may repeat the same operation to produce another CSV without the trailing slashes, but the canonical WordPress URL is with the trailing slash.

It feels a bit awkward that such an obvious things that probably happens often would need such a non-trivial set of steps to do automatically. But software, no matter how user-friendly and “no code”, will require knowledge of basic things like SQL and Regex. And maybe that’s good.

The post Automating the Change of WordPress Permalinks appeared first on Bozho's tech blog.

10 дигитални мерки във връзка с коронавируса

Post Syndicated from Bozho original https://blog.bozho.net/blog/3512

Поради извънредното положение във връзка с вируса COVID-19 има много мерки, които могат и трябва да бъдат взети. Те са комплексни – здравни, информационни, нормативни, организационни, технически. Надали има човек, който може да даде с увереност пълен списък от мерки, които трябва или не трябва да се вземат. Информацията и ситуацията се променя често, Световната здравна организация публикува общи препоръки.

Аз нямам претенции да разбирам от епидемиология, затова няма да обяснявам за изправяне на криви, да строя математически модели на заразата. Не съм и икономист, че да изчислявам ефекта върху икономиката на една или друга мярка. Но все пак има област, в която мога да дам препоръки – дигиталната. Тъй като приоритетът на извънредното положение е социално дистанциране, т.е. да се минимизират контактите между хората, информационните технологии предоставят такава възможност, ако бъдат използвани правилно от публичните институции.

Затова предлагам 9 мерки, които институциите могат да предприемат, за да намалят напрежението, за да не спира животът и да не бъдат излагани хора на излишен риск. Повечето мерки не изискват нормативни изменения, а само ясни правила и организация в публичния сектор.

1. Единна информационна точка с въпроси и отговори. В момента МЗ и МВР публикуват информация на сайтовете си, но тя е или „ето ви една колекция от заповеди, четете“ или откъслечна и трудно проследима във времето. Националният щаб няма сайт. Нужно е да има единна информационна точка, към която всички сайтове на институции, включително на Министерския съвет, да водят. На нея да има актуална информация, както и лесна за ориентиране секция с въпроси и отговори. На едно място, а не препращаща към сайтове на Външно, на МЗ и т.н. Въпроси като „трябва ли да си затворя търговския обект“ (с възможност за избор на типа дейност и динамичен отговор), какво да правя ако се прибирам от чужбина, къде да отида ако имам симптоми, какви са симптомите на вируса, как да използвам електронни услуги и т.н. Може и е редно да бъде добавен и брояч за наличните и използваните тестове за вируса, тъй като това е основен инструмент за контролиране на епидемията. В момента са направени прекалено малко тестове и реално нямаме добра картина върху разпространението.ю

2. Задължително използване на електронно връчване от всички администрации, без нужда от квалифициран електронен подпис – Държавна агенция „Електронно управление“ поддържа система за електронно връчване, през която може по сигурен начин да се обменят документи между гражданите и бизнеса от една страна и администрацията от друга. Той в момента е достъпен само с Квалифициран електронен подпис (за щастие доставчиците на облачни подписи ги пуснаха безплатно за периода на извънредното положение), но трябва и ПИК на НАП да бъде интегриран там спешно. При връчването не трябва да се изисква подпис на самите документи, тъй като те са подадени през система след успешна идентификация (в духа на чл. 22, ал. 5 от Закона за електронното управление).

3. Въвеждане на електронна рецепта. В момента ходенето на лекар е непрепоръчително и затруднено, но хората не спират да боледуват от други неща, само защото има вирус. Аптеките пък не могат да продават лекарства без рецепта (а ако го правят – ги затварят). Този параграф 22 може да бъде решен с някаква форма на електронна рецепта. На пръв поглед изглежда, че задача, която не е решена десетилетия, не може да се реши за 10 дни. Но една базова система, в която лекарите влизат с предварително раздадени данни за достъп и описват какво изписват, като го свързват с ЕГН-то на пациента. След това в аптеката (с използване на предварително получени данни за достъп) проверяват, през компютър или смартфон, ЕГН-то на клиента и ако има издадена рецепта, му дават лекарствата. Разбира се, това са чувствителни данни и защитата на информацията и проследимостта на това кой какво е проверявал трябва да е на ниво. ЕГН-то не трябва да се съхранява в явен вид, а в криптографски трансформиран, за да се избегне риска от изтичане на данни. Една такава проста система може да бъде разработена бързо с директно възлагане.

4. Регламентирането и прилагането на телемедицината е от ключово значение. За да изпише рецепта, лекарят все пак трябва да се запознае със симптомите. Много лекари го правят вече по телефона или чрез чат приложение, но е редно това да бъде регламентирано ясно, в т.ч. каналите и типовете информация, която се предава.

5. Регистър на бизнесите, засегнати от вируса – Министерски съвет предложи да плаща заплатите на служителите, които биха били съкратени заради извънредното положение. За да може държавата да провежда политика по обезщетяване, трябва да знае кой да обезщети. Бизнесите трябва да могат да се вписват в регистър, посочвайки колко и кои служители подлежат на обезщетяване от държавата. В противен случай процесът ще бъде хаотично размятане на документи, а много хора може и да не разберат и да останат без полагащите им се обезщетения.

6. Служебно събиране на информация за административни услуги – подаването на заявление за услга през системата за електронно връчване е само един от компонентите на отдалеченото обслужване. Всяка институция трябва да спазва изискванията на Закона за електронното управление и служебно да събира необходимата ѝ информация. Това е технически възможно с внедряване на Системата за служебен достъп до удостоверения в RegiX. В кризисна ситуация дежурното оправдание „ама моите правила и подзаконова нормативна уредба не позволяват“ могат спокойно да отпаднат.

7. Осигуряване на сигурна среда за отдалечена работа на администрацията. При работа с вътрешни системи е важно те да не бъдат отворени за външния свят, съответно на служителите трябва да бъде осигурена VPN връзка. В противен случай кибератаките няма да закъснеят. Липсата на VPN връзка може да е оправдание служители да не бъдат пускани за отдалечена работа. Поради това такава трябва да бъде изградена спешно.

8. Заседания на колективни органи трябва да могат да бъдат провеждани чрез технически средства (видеоконференции) – както публични такива, така и управителни съвети на дружества и неправителствени организации. Вземането на решения може да бъде удостоверявано от председателстващия заседанието на колективния орган. За това е необходима нормативна промяна.

9. Инициатива за насърчаване и популяризиране на услуги в помощ на населението – много доброволци създават услуги в помощ на населението при вируса – напр. за свързване на хора, имащи нужда от нещо, с такива, които могат да го предоставят. Трябва тези инициативи, често придружени със софтуерни приложения, да бъдат разглеждани от съответен държавен орган и бъдат популяризирани.

10. Дистанционно обучение – тази мярка би била доста по-високо в списъка, но тя вече е въведена. Все пак има доста оперативни и процедурни проблеми, които трябва да бъдат оправяни в бърз порядък. Част от тях са свързани с мащабируемостта на платформите, част – с липсата на ясни правила как да се използват платформите, без това да доведе до хаос.

Има много предложения за мерки и ограничен ресурс, с който те да бъдат изпълнявани. Тук именно е трудната задача по координиране и приоритизиране, за която трябва управленски капацитет. Повечето от предложенията по-горе изискват фокусирани, но минимални усилия и според мен са изпълними и ще помогнат за подобряване на ситуацията.

An AWS Elasticsearch Post-Mortem

Post Syndicated from Bozho original https://techblog.bozho.net/aws-elasticsearch-post-mortem/

So it happened that we had a production issue on the SaaS version of LogSentinel – our Elasticsearch stopped indexing new data. There was no data loss, as elasticsearch is just a secondary storage, but it caused some issues for our customers (they could not see the real-time data on their dashboards). Below is a post-mortem analysis – what happened, why it happened, how we handled it and how we can prevent it.

Let me start with a background of how the system operates – we accept audit trail entries (logs) through a RESTful API (or syslog), and push them to a Kafka topic. Then the Kafka topic is consumed to store the data in the primary storage (Cassandra) and index it for better visualization and analysis in Elasticsearch. The managed AWS Elasticsearch service was chosen because it saves you all the overhead of cluster management, and as a startup we want to minimize our infrastructure management efforts. That’s a blessing and a curse, as we’ll see below.

We have alerting enabled on many elements, including the Elasticsearch storage space and the number of application errors in the log files. This allows us to respond quickly to issues. So the “high number of application errors” alarm triggered. Indexing was blocked due to FORBIDDEN/8/index write. We have a system call that enables it, so I tried to run it, but after less than a minute it was blocked again. This meant that our Kafka consumers failed to process the messages, which is fine, as we have a sufficient message retention period in Kafka, so no data can be lost.

I investigated the possible reasons for such a block. And there are two, according to Amazon – increased JVM memory pressure and low disk space. I checked the metrics and everything looked okay – JVM memory pressure was barely reaching 70% (and 75% is the threshold), and there was more than 200GiB free storage. There was only one WARN in the elasticsearch application logs (it was “node failure”, but after that there were no issues reported)

There was another strange aspect of the issue – there were twice as many nodes as configured. This usually happens during upgrades, as AWS is using blue/green deployment for Elasticsearch, but we haven’t done any upgrade recently. These additional nodes usually go away after a short period of time (after the redeployment/upgrade is ready), but they wouldn’t go away in this case.

Being unable to SSH into the actual machine, being unable to unblock the indexing through Elasticsearch means, and being unable to shut down or restart the nodes, I raised a ticket with support. And after a few ours and a few exchanged messages, the problem was clear and resolved.

The main reason for the issue is 2-fold. First, we had a configuration that didn’t reflect the cluster status – we had assumed a bit more nodes and our shared and replica configuration meant we have unassigned replicas (more on shards and replicas here and here). The best practice is to have nodes > number of replicas, so that each node gets one replica (plus the main shard). Having unassigned shard replicas is not bad per se, and there are legitimate cases for it. Our can probably be seen as misconfiguration, but not one with immediate negative effects. We chose those settings in part because it’s not possible to change some settings in AWS after a cluster is created. And opening and closing indexes is not supported.

The second issue is AWS Elasticsearch logic for calculating free storage in their circuit breaker that blocks indexing. So even though there were 200+ GiB free space on each of the existing nodes, AWS Elasticsearch thought we were out of space and blocked indexing. There was no way for us to see that, as we only see the available storage, not what AWS thinks is available. So, the calculation gets the total number of shards+replicas and multiplies it by the per-shard storage. Which means unassigned replicas that do not take actual space are calculated as if they take up space. That logic is counterintuitive (if not plain wrong), and there is hardly a way to predict it.

This logic appears to be triggered when blue/green deployment occurs – so in normal operation the actual remaining storage space is checked, but during upgrades, the shard-based check is triggered. That has blocked the entire cluster. But what triggered the blue/green deployment process?

We occasionally need access to Kibana, and because of our strict security rules it is not accessible to anyone by default. So we temporarily change the access policy to allow access from our office IP(s). This change is not expected to trigger a new deployment, and has never lead to that. AWS documentation, however, states:

In most cases, the following operations do not cause blue/green deployments: Changing access policy, Changing the automated snapshot hour, If your domain has dedicated master nodes, changing data instance count.
There are some exceptions. For example, if you haven’t reconfigured your domain since the launch of three Availability Zone support, Amazon ES might perform a one-time blue/green deployment to redistribute your dedicated master nodes across Availability Zones.

There are other exceptions, apparently, and one of them happened to us. That lead to the blue/green deployment, which in turn, because of our flawed configuration, triggered the index block based on the odd logic to assume unassigned replicas as taking up storage space.

How we fixed it – we recreated the index with fewer replicas and started a reindex (it takes data from the primary source and indexes it in batches). That reduced the size taken and AWS manually intervened to “unstuck” the blue/green deployment. Once the problem was known, the fix was easy (and we have to recreate the index anyway due to other index configuration changes). It’s appropriate to (once again) say how good AWS support is, in both fixing the issue and communicating it.

As I said in the beginning, this did not mean there’s data loss because we have Kafka keep the messages for a sufficient amount of time. However, once the index was writable, we expected the consumer to continue from the last successful message – we have specifically written transactional behaviour that committed the offsets only after successful storing in the primary storage and successful indexing. Unfortunately, the kafka client we are using had auto-commit turned on that we have overlooked. So the consumer has skipped past the failed messages. They are still in Kafka and we are processing them with a separate tool, but that showed us that our assumption was wrong and the fact that the code calls “commit” doesn’t actually mean something.

So, the morals of the story:

  • Monitor everything. Bad things happen, it’s good to learn about them quickly.
  • Check your production configuration and make sure it’s adequate to the current needs. Be it replicas, JVM sizes, disk space, number of retries, auto-scaling rules, etc.
  • Be careful with managed cloud services. They save a lot of effort but also take control away from you. And they may have issues for which your only choice is contacting support.
  • If providing managed services, make sure you show enough information about potential edge cases. An error console, an activity console, or something, that would allow the customer to know what is happening.
  • Validate your assumptions about default settings of your libraries. (Ideally, libraries should warn you if you are doing something not expected in the current state of configuration)
  • Make sure your application is fault-tolerant, i.e. that failure in one component doesn’t stop the world and doesn’t lead to data loss.

To sum it up, a rare event unexpectedly triggered a blue/green deployment, where a combination of flawed configuration and flawed free space calculation resulted in an unwritable cluster. Fortunately, no data is lost and at least I learned something.

The post An AWS Elasticsearch Post-Mortem appeared first on Bozho's tech blog.

Ролята на бащата през първата година

Post Syndicated from Bozho original https://blog.bozho.net/blog/3486

В началото на месеца Оги стана на една годинка. След година бащинство ми се иска в една малко по-лична публикация да споделя размисли за ролята на бащата в целия процес.

Първата година е „код червено“ – всичко се променя много бързо, сблъсквате се с неща, които за първи път виждате, и за които няма „верен отговор“. Предвид статистиката, че най-много разводи стават през първата година след раждането, периодът поставя под особено напрежение отношенията на родителите.

Приоритетната задача, разбира се, е малкото човече да расте здраво, наспано, нахранено и жизнерадостно. Но това е функция на много неща, в т.ч. информираността, дисциплината и организираността на родителите, но най-вече на тяхната психическа възможност да напредват с „мисията“ бебе.

А колкото и да помага бащата, психическата тежест диспропорционално пада върху майката – тя е тази, която стои по цял ден вкъщи с едно много сладко, но изискващо и не особено разнообразно същество. Без хора, които да ѝ помагат, с които да споделя ежедневието. Сама през голямата част от деня. И тя е тази, чийто живот е най-преобърнат.

Има африканска поговорка, че има нужда от цяло село, за да се отгледа дете. И тя е важала до голяма степен и за нашия континент до неотдавна. Децата са гледани от роднини, съседи, техните деца и внуци. И това е позволявало както много по-лесно предаване на знанията, така и доста по-малко стрес за майката.

В цивилизования свят, обаче, майката и бебето са между четири стени, извън които има предимно непознати, които най-много да се усмихнат на бебето на улицата (но и това е рядко). А тези, от които могат да черпят практични знания и за гледането на бебето, и за психическото си здраве – техните родители – почти нищо не помнят (а дори и да помнят, са препоръки, които междувременно са се променили – напр. дали да се дава вода на бебетата). Организираното излизане с приятелки, дори в рамките на същия квартал, е сложно – синхронизирането на съня на бебетата, особено като са по-малки, е доста трудно.

Говорейки за съня – липсата му утежнява ситуацията допълнително. Дори когато сумарно имаш определено количество сън, ако той е накъсан, качеството му е по-ниско и съответно се чувстваш като парцал. А това е ежедневие за много родители.

Бащата трябва да може да прави всичко, което може майката и е добре да го прави във всеки момент, в който е на разположение (защото през останалото време го прави тя). Невинаги това ще е възможно (напр. след шестия месец приспиването става сложно до невъзможно), но родителите трябва да са оперативно взаимозаменяеми – това спестява доста проблеми.

Бащата не е герой. И трябва да е наясно с това. Сменянето на памперс е лесно. Спането на дивана не е толкова лошо. От пускането на прахосмукачка не падат ръце. Извеждането на разходка е дори приятно. Написването на текст като този също не е геройство. А когато влизам с количката в тясна тоалетна, „не ти е лесно“ е позитивен коментар от придържащия вратата мъж, но изпуска цялата картинка – вкарването на количка в тоалетна не е трудната част. Може да попаднете и на статии, които обясняват, че след раждането майката все пак е „длъжна“ да прави неща за бащата. Това са опасни глупости, които могат да изострят и без това нелекия период (не, няма нужда жената да бъде „лирическият герой“ на Кобилкина).

И със сигурност не си и помисляйте да се скатавате. Изморени сте след работа? Жена ви е по-изморена. Не сте си доспали? Тя не е спала нормално от месеци. Някой ви е изнервил в офиса? Поне е имало с кого да се „напсувате“, тя и това няма.

Така че ролята на бащата, поне през първата година, според мен е да минимизира негативния ефект от съвременния начин на живот върху майката. Не само битово, но и емоционално. Чрез помощ, старание, разбиране, немрънкане, говорене, излизане, правене на неща заедно. Няма да се получава перфектно. Ако сте несръчни и разсеяни, колкото мен, ще е много далеч от перфектно. Вероятно ще е недостатъчно. Ще има криви моменти. Но от моята гледна точка това е правилният подход. Това означава и от възможно най-рано бащата да бъде равноправен родител, а не „детегледачка“.

А в по-общ план трябва да помислим как да решим дългосрочно тези проблеми. Явно е, че не можем да гледаме бебетата на улицата, заедно със съседите. Бабите и дядовците ни са работещи хора и не могат да помагат през цялото време. А оставянето на тримесечно бебе на бавачка с адаптирано мляко (както се случва в САЩ, например, поради липса на регламентирано майчинство), не мисля, че е най-доброто за бебето. Нямам конкретни предложения, но това майките да не бъдат гледани като „истерични бг-мами“, а да се чувстват добре трябва да е приоритет не само на бащите, а на цялото общество. По очевидни причини.

Квалифициран електронен подпис на юридическо лице не съществува

Post Syndicated from Bozho original https://blog.bozho.net/blog/3494

Юридическите лица у нас (или по-точно законните им представители) си имат квалифицирани електронни подписи, с които ползват електронни услуги от държавата (и по-рядко – подписват договори, макар че това би било чудесно). Само че такова нещо като квалифициран електронен подпис на юридическо лице няма в правната рамка на електронните подписи. Да цитирам Регламент (ЕС) 910/2014, който урежда материята:

14) „удостоверение за електронен подпис“ означава електронен атестат, който свързва данните за валидиране на електронен подпис с физическо лице и потвърждава най-малко името или псевдонима на това лице

Та, електронните подписи на юридически лица доставчиците ги водят делегирани електронни подписи (или нещо подобно), за да бъдат все пак коректни спрямо законодателството. Но какво всъщност правят – вписват ЕИК (и името) на фирмата в удостоверението за квалифициран електронен подпис. Толкова. Това, обаче е голям проблем. И голяма глупост. Тя е глупост както на администрацията, която изисква ЕИК в удостоверението за електронен подпис, така и на доставчиците, че го издават. Нека да обясня защо.

Вписването на ЕИК в КЕП (наложило се съкращение, значещо „квалифициран електронен подпис“, но реално визиращо удостоверението за квалифициран електронен подпис или по терминологията на eIDAS – квалифицираното удостоверение за електронен подпис) означава едно нещо – този човек, който е приносител на удостоверението, има представителна власт по отношение на дружеството, вписвано в удостоверението. Тази представителна власт (дали в качеството му на управител или упълномощено от управител лице) се проверява в момента на издаването на удостоверението за електронен подпис и се вписва там. Оттам нататък администрациите, предоставящи електронни услуги (напр. НАП), разчитат на вписаното ЕИК в удостоверението. Проблемът идва, когато управител бъде сменен или пълномощно бъде оттеглено преди изтичане на срока на КЕП-а (който може да се издава за три години).

В този момент човек без представителна власт продължава да може да представлява дружеството пред администрацията (а и някои банки) и това ще бъде прието, защото удостоверението е валидно. Какви щети могат да бъдат нанесени така – не съм навлизал в такива хипотези, но най-малкото може да бъде причинено неудобство на новия управител.

А не трябва ли, при смяна на управителя, съдружниците да уведомят всички доставчици на електронни подписи за промяната, за да могат те да прекратят действието на удостоверението? По принцип може, само че надали много хора ще се сетят. Освен това, при единния цифров пазар, това значи уведомяване не само на няколко български доставчици, а на всички доставчици в ЕС. Защото управителят може през това време да си е извадил КЕП в Белгия (ако е успял да убеди белгийския доставчик да впише допълнително поле за ЕИК, така че да работи с е-услугите). Така че трябва да се уведомят всички доставчици в ЕС. Поне ги има на списък от европейската комисия, но задачата става безумна.

Друг вариант би бил доставчиците на електронни подписи да получават всеки ден от търговския регистър променените обстоятелства и ако са издали удостоверение на някой, който вече не е управител (т.е. не са налице обстоятелствата, на база на които е издадено удостоверението), да го прекратят автоматично. Това е възможно, но безмислено, тъй като доставчикът е грешното място да се случва това.

Правилният подход е да няма ЕИК в удостоверението, да няма изобщо различна услуга за юридически лица. С моя личен КЕП трябва да мога да се идентифицирам и заявявам услуги на всички дружества, които представлявам (въпросът дали КЕП трябва да може да се ползва за идентификация е отделен, разгледал съм го тук). В момента на идентификация, без значение дали с КЕП или с друго средство, доставчикът на услугата трябва в реално време да проверява в Търговския регистър или регистъра Булстат дали представлявам съответното дружество. В повечето случаи отговорът се получава еднозначно и нещата могат да продължат автоматизирано. В редки случаи на по-сложна представителна власт (напр. само заедно за определени неща), тъй като Търговският регистър не поддържа номенклатури за такъв тип представителство, се налага ръчна проверка от страна на предоставящия услугата, но това са много малка част от случаите. Когато става въпрос пък за упълномощени лица, автоматичната проверка трябва да работи в за съжаление все още несъществуващия регистър на овластяванията по Закона за електронната идентификация.

Вместо това доставчиците на услуги или изобщо не признават личния КЕП като вариант да се идентифицираш и заявиш услуга като представител на юридическо лице, или изискват да отидеш на място (НАП, вас гледам), за да потвърдиш с декларация, че ти наистина си управител на това дружество (да, НАП искат да се подпишеш, че данните от Търговския регистър са верни, не си го измислям. Сигнализирах на Агенция по вписванията, но мисля, че нищо не направиха по въпроса, даже не ми отговориха). И в крайна сметка администрацията разчита на доставчиците на електронни подписи да са направили необходимите проверки, а не на актуалните данни в Търговския регистър, които са единствените, на които може да се има доверие в реално време. А първичните администратори на данни имат задължение да предоставят данни за представителна власт в реално време (чл. 24б от Закона за електронното управление). И Агенция по вписванията дори го спазва отчасти.

Не знам кой и защо е измислил и приел този начин на работа и дали просто не е е наложил като много по-прост, защото е по-лесно да прочетеш едно поле от удостоверение за електронен подпис, отколкото да правиш връзка с Търговския регистър. Но това е неправилно, незаконно (чл. 27 от ЗЕУ) и създава излишни рискове.

Но както често се случва и тук практиката се разминава от нормативната уредба и от правилния подход. И почти никой не може да каже на администрациите да сменят тази своя практика. Защото те винаги така са го правили. Доставчиците на електронни подписи пък изобщо не се оплакват, че могат да продават на тройна цена същата услуга (с усложнението да направят проверка в Търговския регистър при издаване). И така всичко си тече. Не че това е фатален проблем, но е един от многото проблеми, едно от многото малки неща, които са не баш както трябва. И като се съберат всички тези малки неща, се оказва, че имаме нездрави основи, на които трудно можем да построим смислено електронно управление.

Running a Safe Database Cluster in AWS With Auto-Scaling Groups

Post Syndicated from Bozho original https://techblog.bozho.net/running-a-safe-database-cluster-in-aws-with-auto-scaling-groups/

When you have to run a scalable application on AWS, your database must also be scalable. It’s easier to scale the stateless application layer, where each node is mostly disposable – even if a node in a 3-node cluster fails, you can just fire up another one and nobody notices.

The database layer is stateful and therefore there’s a risk to lose data. Having just a single node is not an option, as a node can always go down and that would mean downtime. So you need multiple nodes in a cluster to make sure your application is highly available and fault tolerant (I won’t go into the differences in terminology).

What database am I talking about? It doesn’t matter. It can be a SQL or a NoSQL database – each has some form of clustering available. Whether it’s active-active or active-passive.

Now, for AWS in particular, you can choose RDS (or another managed option), which will handle it for you. But if there’s no managed option (e.g. Cassandra) or you don’t feel the managed option is giving you enough control, or is more expensive, or the version you require is not available, you have to manage the database layer yourself. I won’t go into the details of how to configure the database-specific clustering – you should check the documentation of the particular database for that. I’ll try to give some tips how to safely run your infrastructure that supports the database cluster.

And here come auto-scaling groups. They allow you have have a group of identical nodes (based on a launch configuration) and the ASG makes sure you always have at least X healthy nodes by starting new nodes if existing ones fail( they can automatically kill unhealthy nodes (that is, nodes that do not respond to automated healthchecks)).

That’s awesome for application nodes, but it can be an issue with database nodes. You don’t necessarily want your database node killed if it gets unresponsive for a while. That’s why below I’ve compiled a list of tips to avoid pitfalls. Unfortunately, many of them are not available through CloudFormation, so you have to do them manually. And document them so that you don’t forget in case you need to recreate the stack:

  • Set the minimum number of nodes to 1. It protects from accidentally setting the “Desired” count to 0 as part of experimenting with other, unrelated ASGs
  • Make sure you have enabled termination protection for each instance as well as scale-in termination protection per ASG.
  • In the ASG settings there’s “Suspended Processes”. Make sure you suspend “Terminate” and “ReplaceUnhealthy”.
  • Make sure that in your LaunchConfiguration the EBS volume is not deleted in case of termination. Why do you need that, given that you have disabled all termination options? Well, termination can occasionally happen due to issues with the underlying host, or a node may be scheduled for decommission
  • If at some point you need to restore from an EBS volume, 1. let the ASG spawn a new node 2. temporarily add “Launch” to the suspended actions 3. Detach the root volume of the node 4. attach the old EBS volume to /dev/xvda 5. start the node.
  • Setup a lifecycle policy (through CloudFormation or manually) to do a backup on the database EBS volumes. Make sure you set the proper tags to the volumes (and this can only be done manually)
  • Make sure the ASG can spawn instances in multiple availability zones (in case one goes down)

If you follow that, your auto-scaling groups will not behave exactly as auto-scaling groups. You can still configure automatically increasing the number of nodes in case of increased load, but the rest of the features are rarely a good idea for database layers – you’d prefer to resolve your database issues on existing machines, even if stopped temporarily, rather than just spawn new ones.

But you should embrace failure. Even with all termination protections, you have to assume everything may fail and die and you should have a clear path to restoring your nodes.

The post Running a Safe Database Cluster in AWS With Auto-Scaling Groups appeared first on Bozho's tech blog.