All posts by Bozho

„Тук не е информация“ като символ

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

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

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

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

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

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

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

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

Но като погледнеш какво е отчетено – обикновено изхарчени пари, закупени предмети (или лицензи) и най-много някое проведено обучение. В повечето стратегически документи в държавата (стратегии, пътни карти, екшън планове) твърде рядко има каквито и да било индикатори за успех, а когато такива има, те не са свързани с отчитане на постигнатото, а с отчитане на извършеното. Пренесохме 20 чувала! Само че реално 10 чувала са отишли и после са се върнали. Работа е свършена, резултат няма.

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

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

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

Колкото и да не ми се иска текстът да звучи негативно, това е неизбежно. Само че има как тук да бъде информация. Да има информация. Да бъде удобно.

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

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

Материалът „Тук не е информация“ като символ е публикуван за пръв път на БЛОГодаря.

Content-Security-Policy Nonce with Spring Security

Post Syndicated from Bozho original https://techblog.bozho.net/content-security-policy-nonce-with-spring-security/

Content-Security-Policy is important for web security. Yet, it’s not mainstream yet, it’s syntax is hard, it’s rather prohibitive and tools rarely have flexible support for it.

While Spring Security does have a built-in Content Security Policy (CSP) configuration, it allows you to specify the policy a a string, not build it dynamically. And in some cases you need more than that.

In particular, CSP discourages the user of inline javascript, because it introduces vulnerabilities. If you really need it, you can use unsafe-inline but that’s a bad approach, as it negates the whole point of CSP. The alternative presented on that page is to use hash or nonce.

I’ll explain how to use nonce with spring security, if you are using .and().headers().contentSecurityPolicy(policy). The policy string is static, so you can’t generate a random nonce for each request. And having a static nonce is useless. So first, you define a CSP nonce filter:

public class CSPNonceFilter extends GenericFilterBean {
    private static final int NONCE_SIZE = 32; //recommended is at least 128 bits/16 bytes
    private static final String CSP_NONCE_ATTRIBUTE = "cspNonce";

    private SecureRandom secureRandom = new SecureRandom();

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        byte[] nonceArray = new byte[NONCE_SIZE];

        secureRandom.nextBytes(nonceArray);

        String nonce = Base64.getEncoder().encodeToString(nonceArray);
        request.setAttribute(CSP_NONCE_ATTRIBUTE, nonce);

        chain.doFilter(request, new CSPNonceResponseWrapper(response, nonce));
    }

    /**
     * Wrapper to fill the nonce value
     */
    public static class CSPNonceResponseWrapper extends HttpServletResponseWrapper {
        private String nonce;

        public CSPNonceResponseWrapper(HttpServletResponse response, String nonce) {
            super(response);
            this.nonce = nonce;
        }

        @Override
        public void setHeader(String name, String value) {
            if (name.equals("Content-Security-Policy") && StringUtils.isNotBlank(value)) {
                super.setHeader(name, value.replace("{nonce}", nonce));
            } else {
                super.setHeader(name, value);
            }
        }

        @Override
        public void addHeader(String name, String value) {
            if (name.equals("Content-Security-Policy") && StringUtils.isNotBlank(value)) {
                super.addHeader(name, value.replace("{nonce}", nonce));
            } else {
                super.addHeader(name, value);
            }
        }
    }
}

And then you configure it with spring security using: .addFilterBefore(new CSPNonceFilter(), HeaderWriterFilter.class).

The policy string should containt `nonce-{nonce}` which would get replaced with a random nonce on each request.

The filter is set before the HeaderWriterFilter so that it can wrap the response and intercept all calls to setting headers. Why it can’t be done by just overriding the headers after they are set by the HeaderWriterFiilter, using response.setHeader(..) – because the response is already committed and overriding does nothing.

Then in your pages where you for some reason need inline scripts, you can use:

<script nonce="{{ cspNonce }}">...</script>

(I’m using the Pebble template syntax; but you can use any template to output the request attribute “csp-nonce”)

Once again, inline javascript is rarely a good idea, but sometimes it’s necessary, at least temporarily – if you are adding a CSP to a legacy application, for example, and can’t rewrite everything).

We should have CSP everywhere, but building the policy should be aided by the frameworks we use, otherwise it’s rather tedious to write a proper policy that doesn’t break your application and is secure at the same time.

The post Content-Security-Policy Nonce with Spring Security appeared first on Bozho's tech blog.

2020: Сблъсък на дезинформацията с живота и здравето

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

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

Няма да опитвам да оборвам всички измислици относно COVID-19 ваксините – това вече са го правили много хора с по-подходяща квалификация от мен (биолози, лекари). Накратко – не, във ваксината няма чипове. Не, не се умира от нея. Не, не ни променя ДНК-то. Не, не е направено „много бързо“ (а е стъпила на години изследвания на предишната епидемия с коронавирус в Азия – SARS-CoV-1, както и на MERS в близкия изток). Не, хората, които си слагат ваксина по телевизията не си инжектират водя или глюкоза. И т.н.

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

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

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

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

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

Хората не са свикнали да отсяват такъв поток от информация и съответно той директно влияе не възприятието им за света. А кой се грижи за отсяването на информацията? Социалните мрежи. Фейсбук, Гугъл (YouTube), Туитър. Техните алгоритми промотират или ограничават разпространението на дадено съдържание – на новина, на статус, на снимка.

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

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

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

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

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

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

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

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

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

Материалът 2020: Сблъсък на дезинформацията с живота и здравето е публикуван за пръв път на БЛОГодаря.

Releasing Often Helps With Analyzing Performance Issues

Post Syndicated from Bozho original https://techblog.bozho.net/releasing-often-helps-with-analyzing-performance-issues/

Releasing often is a good thing. It’s cool, and helps us deliver new functionality quickly, but I want to share one positive side-effect – it helps with analyzing production performance issues.

We do releases every 5 to 10 days and after a recent release, the application CPU chart jumped twice (the lines are differently colored because we use blue-green deployment):

What are the typical ways to find performance issues with production loads?

  • Connect a profiler directly to production – tricky, as it requires managing network permissions and might introduce unwanted overhead
  • Run performance tests against a staging or local environment and do profiling there – good, except your performance tests might not hit exactly the functionality that causes the problem (this is what happens in our case, as it was some particular types of API calls that caused it, which weren’t present in our performance tests). Also, performance tests can be tricky
  • Do a thread dump (and heap dump) and analyze them locally – a good step, but requires some luck and a lot of experience analyzing dumps, even if equipped with the right tools
  • Check your git history / release notes for what change might have caused it – this is what helped us resolve the issue. And it was possible because there were only 10 days of commits between the releases.

We could go through all of the commits and spot potential performance issues. Most of them turned out not to be a problem, and one seemingly unproblematic pieces was discovered to be the problem after commenting it out for a brief period a deploying a quick release without it, to test the hypothesis. I’ll share a separate post about the particular issue, but we would have to waste a lot more time if that release has 3 months worth of commits rather than 10 days.

Sometimes it’s not an obvious spike in the CPU or memory, but a more gradual issue that you introduce at some point and it starts being a problem a few months later. That’s what happened a few months ago, when we noticed a stead growth in the CPU with the growth of ingested data. Logical in theory, but the CPU usage grew faster than the data ingestion rate, which isn’t good.

So we were able to answer the question “when did it start growing” in order to be able to pinpoint the release that introduced the issue. because the said release had only 5 days of commits, it was much easier to find the culprit.

All of the above techniques are useful and should be employed at the right time. But releasing often gives you a hand with analyzing where a performance issues is coming from.

The post Releasing Often Helps With Analyzing Performance Issues appeared first on Bozho's tech blog.

Да оправим наредбата за електронните рецепти

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

Министерският съвет е приел изменение на наредбата за реда за отпускане на лекарствени продукти, добавяйки текстове за електронна рецепта., която е обнародвана днес.

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

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

Ето и моите критики и предложения:

  • Наредбата казва, че „електронните предписания се издават, въвеждат, обработват и съхраняват чрез специализиран медицински и аптечен софтуер.“. Електронните рецепти трябва да се съхраняват в Националната здравна информационна система (НЗИС), а не в медицинския и аптечен софтуер. Там може да се съхраняват временно и за удобство, но централното място за съхранение трябва да бъде НЗИС. В следваща алинея наредбата урежда „висящото“ положение на прогресивно появяваща се НЗИС, което може да звучи добре, но няма как да е нормативен акт. Наредба не може да казва „като стават някакви неща, ще видим как ще ги ползвате“.
  • Наредбата казва, че „За издаването на електронно предписание лекарят или лекарят по дентална медицина се идентифицира чрез КЕП“. Ред за идентифициране с КЕП има временен по наредба към Закона за електронното управление и е редно тази наредба да препрати към нея, защото иначе „идентификация с КЕП“ не значи нищо. А е важно в този контекст как точно ще се извършва идентификацията. Правилният подход е от квалифицираният електронен подпис на лекаря да се вземе ЕГН-то, то да се провери в регистъра на лекарите (или фармацевтите, за които имат сходен ред в следващия член) (вместо, например, да се изисква вписване на служебен номер в КЕП). Също така, идентификация трябва да може да се извършва и по реда на Закона за електронната идентификация. Но при издаване, процесът на идентификация може всъщност да е излишен – предвид, че рецепта се издава чрез софтуер при лекаря (и се проверява в аптеката), лекарят вече е влязъл в системата. Наредбата не казва пред кого се идентифицират, така че стъпката може да се премахне.
  • Според наредбата „При електронното предписване на лекарствения продукт се извършва автоматична проверка в регистъра [..]“ – тук е важно да се отбележат техническите параметри на тази проверка, т.е. посоченото по-горе – че на база на ЕГН се извлича УИН. Дали регистъра на БЛС и на фармацевтите поддържат такава справка? И да не поддържат, може бързо и лесно да се добави, тъй като я има. Но по-проблемното е тази алинея е, че тя не представлява норма, а прави разказ. Нормативните актове създават права и задължения. Не може да кажеш „се прави проверка“. Казваш кой е длъжен да направи тази проверка. Освен, че е лош нормативен текст, наистина не става ясно кой е длъжен да я прави – дали доставчикът на болничен и аптечен софтуер, или, както е правилно – НЗИС, откъдето трябва да минават всички рецепти. Само че НЗИС не е лице, на което може да се вменят задължения, така че трябва ясно да се напише, че Министерството на здравеопазването прави тази проверка чрез НЗИС.
  • Подписване на рецептата с КЕП според наредбата се прави след проверка в регистрите, а е редно да е обратно – в момента на изпращане на подписаната рецепта към НЗИС, да се проверят всичките ѝ реквизити.
  • След като пациентът отиде в аптеката,“ Магистър-фармацевтът извършва действия по идентифициране на издаденото електронно предписание, при които като водещ критерий използва ЕГН на пациента.“ – това тука е доста проблемно. Според публичните изказвания от преди месец идентифицирането на рецептата трябваше да става по ЕГН и последните 4 цифри от кода на рецептата. Този текст не казва как се прави проверка, „водещ критерий“ е неясно. Може ли само по този критерий (не би трябвало)? По кои други критерии може – ЕГН+номер на лична карта, ЕГН+4 цифри от номер на рецепта? По принцип е добре да се спести разпечатване на електронни рецепти (защото това би ги обезсмислило), така че предложението, което аз бях направил пред 8 месеца беше ЕГН+номер на лична карта, или поне част от номер на личната карта. Фармацевтът може да вижда няколко активни рецепти и е добре да знае коя да изпълни. Дали това трябва да се опише в наредба е спорно, но предвиждам обърквания, поне в началото
  • „При осигурени технически и организационни условия за това от Министерството на здравеопазването и НЗОК“ – това е много неясен критерий, за да го има в нормативен акт. Редно е държавата първо създаде условията и тогава да налага срокове.
  • Липсват изисквания за сигурност и защита на данните – в какъв вид НЗИС обработва и съхранява рецептите? След колко време те се изтриват или анонимизират? Има ли проследимост кой какви справки е правил – напр. фармацевти по кои ЕГН-та са търсили и съответно има ли отпуснати след това лекарства. Кой до каква функционалност има достъп? Как е уреден достъпа до НЗИС в МЗ, включително за справочни функционалности? Комисията за защита на личните данни дала ли е становище по проекта на наредба?
  • Липсват ясни инструкции за доставчиците на болничен и аптечен софтуер – къде и какви номенклатури да ползват и имат ли гаранция, че те са актуални. Наредбата казва, че „Програмните интерфейси и номенклатурите за обмен на информация между медицинския и аптечен софтуер и НЗИС се актуализират текущо“, но това е неясно и неприемливо. Липсва препратка към чл. 14 от наредбата към Закона за електронно управление, която урежда поддържането на версии на програмните интерфейси – не трябва да може МЗ/НЗИС да смени от днес за утре един итнерфейс и всичко да се счупи.
  • Не е уреден форматът на кода на рецептата. Това е малък проблем, но обикновено се урежда с нормативния акт, който въвежда дадена система. Бих предложил да следва предписанията на чл. 4, ал. 5 от наредбата към ЗЕУ, т.е. да ползва UUID (RFC 4122), особено ако няма да се налага да се цитират 4 цифри/букви от него

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

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

Материалът Да оправим наредбата за електронните рецепти е публикуван за пръв път на БЛОГодаря.

Електронно трудово досие?

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

Пандемия. Работа от вкъщи. Обаче…

Трудовото законодателство е над тия неща и съответно работодателите и служителите трябва да си общуват на хартия за неща като болнични, отпуски, фишове и други.
Сега запознатите ще кажат „ама то от 2018г. има наредба за електронно трудово досие“. А-ха! Има, ама… все едно няма:

(4) Електронни изявления между страните по трудовото правоотношение се връчват чрез услуга за електронна препоръчана поща.

Т.е. не може ти просто да си изпратиш неща по имейла, а служителите да ги подпишат в Adobe Reader (дали с КЕП или с друг вид подпис, няма значение), и после да ги сложиш в папката в OneDrive/Google Drive на съответния служител. Не. Трябва да ползваш удостоверителна услуга по смисъла на регламента (или да си изградиш такава). И също така:

(3) Всяко действие в системата се удостоверява с квалифициран електронен времеви печат.

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

Да, някои много, много иновативни компании може и да изградят такава система (или някой да направи такава система „като услуга“), да сключат допълнителни споразумения със служителите за ползването на системата, да се закачат към някоя удостоверителна услуга за препоръчана електронна поща, и да уговорят какъв вид електронен подпис приемат.

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

Има, разбира се, компании, които предоставят услуга, която е в съответствие с наредбата: EHR.bg, timeoff, Тереза. Което е разбираемо и хубаво – когато се появи някаква свръхрегулация, се намира кой да предостави услуга, която да улесни регулираните субекти, срещу съответното заплащане. Признавам, не съм разглеждал тези софтуери/услуги в детайли и дали отговарят на всички изисквания (бих искал да видя квалифицирания печат, напр., както и реализацията на услуга за препоръчана електронна поща)

Само че как щеше да е по-добре да стане това, така че да не се въвежда допълнителна бюрокрация, нужда от допълнителен доставчик, разходи и увеличен риск заради споделянето на данни за трудовото правоотношение с трети лица, но в същото време правата на служителите да са защитени? Без да оставаме на хартия, (както с трудовата книжка)

  • Ориентиране на наредбата не към имагинерни системи за електронни трудови досиета, а към т.нар. HRM системи (Human Resource Management, системи за управление на човешки ресурси)
  • Наредбата да определи какво счита за електронен подпис, защото не само квалифицираният е такъв – „read receipt“ може да бъде електронен подпис (оставил е данни в електронен вид до изходящото писмо, което е също данни в електронен вид), може да бъде сканиран подпис, сложен в Adobe Reader, може да е дори нарисуван на екран подпис. Може да бъде вход и поставяне на инициали в документ в облачна услуга, която пази история на редакциите и удостоверява потребителя с неговите данни за достъп. Не че в момента наредбата ги изключва, но в общия случай бизнеса не влиза в тези правно-философско-технически дебри на Регламент (ЕС) 910/2014
  • Отпадане на изискването на услуга за препоръчана електронна поща. Да, трябва да се удостовери, че служителят наистина е получил документа (а работодателят не е направил това вместо него), но при трудови спорове, които биха били редки за най-тривиалните неща като отпуски и болнични, обстоятелствата мога да се установят от вещо лице – при облачни email услуги по-лесно, при локални – със съответните проверки на логове както на сървър, така и на компютъра на служителя.
  • Отпадане на изискването за квалифицирани електронни времеви печати – да, времето на настъпване на събитията е важно. При използване на облачни HR системи биха били изпълнени условията за (обикновен) времеви печат, тъй като датите в системата не могат да бъдат манипулирани от работодателя. При локално инсталирана такава би съществувал потенциален риск от манипулиране на времето на настъпване на някакво събитие, но отново – ако има копие за служителя, на негов компютър, както и свидетели, би било възможно при трудов спор да се установи истината. Хартиени документи също могат да бъдат подправени, като и в двата случая това може да бъде документно престъпление.

С други думи – относно поне най-масовите документи, като фишове за заплата, болнични и отпуски, „качени са в HR системата и са прегледани от служителя“ или „изпратени са по имейл“ или „качени са в съответната папка на служителя в Google Drive / OneDrive / на FTP-то и има логове за достъпа до тях“ трябва да е напълно валиден начин за водене на електронно трудово досие. Що се отнася до анекси и допълнителни споразумения и други по-чувствителни документи, те могат да изискват квалифициран електронен подпис или да се случват на хартия, ако служителят няма такъв. Но заради хипотезата на трудов спор във връзка с подправени документи за изплатени суми, болнични или отпуски, не бива да осакатяваме и свръхрегулираме цялата трудова документация, на практика оставяйки я в хартиения свят.

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

Материалът Електронно трудово досие? е публикуван за пръв път на БЛОГодаря.

Syntactic Sugar Is Not Always Good

Post Syndicated from Bozho original https://techblog.bozho.net/syntactic-sugar-is-not-always-good/

This write-up is partly inspired by a recent post by Vlad Mihalcea on LinkedIn about the recently introduced text blocks in Java. More about them can be read here.

Now, that’s a nice feature. I’ve used it in Scala several years ago, and other languages also have it, so it seems like a no-brainer to introduce it in Java.

But, syntactic sugar (please don’t argue whether that’s precisely syntactic sugar or not) can be problematic and lead to “syntactic diabetes”. It has two possible issues.

The less important one is consistency – if you can do one thing in multiple, equally valid ways, that introduces inconsistency in the code and pointless arguments of “the right way to do things”. In this context – for 2-line strings do you use a text block or not? Should you do multi-line formatting for simple strings or not? Should you configure checkstyle rules to reject one or the other option and in what circumstances?

The second, and bigger problem, is code readability. I know it sounds counter-intuitive, but bear with me. The example that Vlad gave illustrates that – do you want to have a 20-line SQL query in your Java code? I’d say no – you’d better extract that to a separate file, and using some form of templating, populate the right values. This is certainly readable when you browse the code:

String query = QueryUtils.loadQuery("age-query.sql", timestamp, diff, other);
// or
String query = QueryUtils.loadQuery("age-query.sql", 
       Arrays.asList("param1Name", "param2Name"), 
      Arrays.asList(param1Value, param2Value);

Queries can be placed in /src/main/resources and loaded as templates (and cached) by the QueryUtils. And because of the previous lack of text blocks, you would not prefer ugly string concatenated queries inside your code.

But now, with this feature, you are tempted to do that, because, well, it looks good. Same goes for Elasticsearch queries, for JSON templates and whatnot. With this “sugar” you have more incentive to just put them in the code, where they, arguably, make the code less readable. If you really have to debug the query, as opposed to assuming its semantics by its name and relying on a proper implementation, you can easily go to age-query.sql and work with it. Just like when you extract a private method with some implementation details so that it makes the calling method more readable and easy to follow.

Both problems have manifested themselves in my Scala experience, which I’ve summed up in my talk “Scala – the good, the bad and the very ugly” (only slides available). Scala allows you to express things nicely and in multiple ways, which leads to inconsistencies and horrible code readability in some cases.

Counter intuitively, sometimes the syntactic improvements may be worse for code readability. Because they introduce complexity and because they make it easier to do the wrong thing.

That’s not a universal complaint, and certainly syntactic sugar is needed – you don’t have to write List<String> list = new ArrayList<String>() if you can use the diamond operator. But each such feature should be well thought not just for how easy it makes to write the code, but also how easy it is to read it, and more importantly - what type of code it incentivizes.

The post Syntactic Sugar Is Not Always Good appeared first on Bozho's tech blog.

Нужни са ни по-добри данни за COVID-19

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

Смятам за нужно е да се направят две уточнения относно данните за COVID-19 у нас, тъй като напоследък се разпространяват алтернативни тълкувания.

  1. Броят заразени НЕ е достигнал плато и не намалява. Да, това казва официалната статистика за брой заразени, но тук има два фактора. Първият е, че сме на 40% позитивни тестове. Това прави статистиката безполезна – препоръката на СЗО е до 3% позитивни, за да имаш някакво адекватно проследяване на заразата. Също така общият брой тестове намалява, тъй като са скъпи, държавата до съвсем скоро не ги покриваше (а сега ги покрива при определени условия) и хората спряха да си ги правят – не им се изискват за пътуване, за какво да ги правят, като има безплатни антигенни, които обаче не влизат в статистиката. Така че – не, няма спад на заразените, но нямаме реална картина колко са всъщност.
  2. Броят смъртни случаи от COVID също не е достигнал плато. Тук е много важна методиката за отчитане на тези данни, а такава публично достъпна аз поне не намерих. Но допускането ми (и информация, която получавам от различни места) е, че методиката е доста консервативна – т.е. за починал с COVID се счита само ако имаш положителен PCR и си починал скоро след това. Това не включва починали вкъщи, починали в спешна помощ преди да е направен (и излязъл?) PCR. А при това натоварване на болниците, там отиват само спешните случаи, останалите си стоят вкъщи, защото няма места.

И в двата случая (а и при всички данни в реалния свят) и важно какъв е контекстът и какво значат данните в него, а не просто изсипани в ексел.

Единствената статистика, на която можем да разчитаме в момента, е тази, която излиза от НСИ всеки вторник – на общата смъртност в страната. Тя не разграничава по причина на смъртта, но дава доста ясна картина колко много се е повишила смъртността спрямо спрямо минали години.

Какво може да се направи, чисто от гледна точка на данните, защото каквото виждаме ние, вероятно това вижда и властта, а то е много подвеждащо и съответно се разчита на разкази и възприятия:

  • да се регистрират (отделно) и позитивните антигенни тестове. Тук се надявам процесът и интерфейсът да са удобни, за да не създава това голяма административна тежест
  • да се публикува методиката за отчитане на смъртни случаи с COVID и тя да се ревизира, така че да включи категория с предполагаемо починали от COVID (т.е. такива, които преди смъртта са имали симптоми или позитивен антигенен тест). Може в отделна графа да се публикува, за да е ясно кое какво е.
  • в периода на епидемичната обстановка, НСИ да публикува данните за смъртността всеки ден или на три дни – данните се вземат от смъртните актове, регистрирани от ГД ГРАО, така че там няма поле за тълкуване, извън факта, че при натоварването на системата, смъртни актове могат да излизат със закъснение. НСИ може да отичта и това – дата на вписване на смъртния акт спрямо дата на смъртта, като по този начин се отчита увеличеното натоварване.

Защо трябва да се занимаваме с числа, вместо да се фокусираме върху лекуването на хората? Не е „вместо“. Но без адекватна картина, всяка управленска мярка е стреляне в тъмното.

И по-важното – създават се алтернативни реалности дори сред над средно интелигентни хора, които не са попаднали още в света на конспирациите с „чипиране с 5G и ваксини“, но не са влезли навътре в естеството на данните. Ако гледаме данните за заразяване и за смъртност от COVID, от локдаун няма нужда – всичко е точно. Само че на тях изобщо не може да се разчита. Това пък е фактор за хората – доколко мотивирани да спазват мерките или да вярват на алтернативните факти, че „то нещата не са толкова тежки“.

Материалът Нужни са ни по-добри данни за COVID-19 е публикуван за пръв път на БЛОГодаря.

Как наистина да получим електронна идентификация

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

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

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

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

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

Трябва изпълнителят да реализира този процес удобно, със стандартни приложения за различните мобилни операционни системи, така че процесът да бъде: 1. натискане на бутон „идентифицирай се“ при заявяване на услуга 2. Излизане на съобщение на телефона за очаквана идентификация 3. допиране на картата и написване на PIN (може и в обратен ред, за по-голямо удобство) 4. Успешна идентификация. Трябва да се обърне внимание и на сигурността на безконтакното четене. Към 2016 стандартите по темата не бяха масово възприети, така че изпълнителят и възложителят трябва да преценят кой е най-актуалният начин.

Персонализиране на други носители – електронната идентификация не е само „чип в личната карта“. Всъщност чипът в личната карта е само една от много възможности. Трябва в рамките на издаването на удостоверение за електронна идентичност да се даде опция за записването му (заедно с частния ключ) на смартфон или на друга карта. Записването на частен ключ на телефон към 2016 г. не беше сигурно (имаше известни атаки), но 4 години по-късно вече е. И в нормативната уредба, и в заданието е заложена възможност за издаване на eID чрез вече съществуващо eID. Т.е. може с еднократно използване на личната карта да се създаде нов частен ключ и удостоверение на телефона и всяка следваща идентификация да не изисква докосване на картата и писане на PIN (а използване на сензора за пръстов отпечатък). Тези опции са заложени и напълно възможни, но трябва и възложителят, и изпълнителят да съблюдават те да се случат по този начин.

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

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

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

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

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

Не на последно място, трябва да бъде реализирана идентификация на юридически лица чрез връзка в реално време с Търговския регистър (и РЮЛНЦ, и Булстат), за да се избегнат проблемите, които произтичат от настоящото решение с КЕП. Това предполага надграждане на системи и понякога промяна на процеси.

Цялостна архитектура на федерираната идентификация – националната схема за електронна идентификация е само една от няколко опции. Вече има частни схеми за идентификация, отдавна има всевъзможни ПИК-ове, които макар и от ниско ниво, минават за идентификация по Регламент 910/2014. Има и необходимост да се поддържат електронните идентификации на всички държави членки. Трябва максимално бързо да бъде разписана архитектура на федерирана идентификация, която да позволява на гражданите да ползват всяка услуга с подходящо за целта средство. Първо, с надграждането на административния регистър (което също трябваше да е станало отдавна) трябва да се добавят нивата на осигуреност на идентификацията, която дадена услуга изисква. След това трябва да има т.нар. eIDAS възел, който да позволява интеграция с европейските схеми.

Трябва да бъде подготвена архитектура и на местно ниво – как частни схеми и/или частни центрове за електронна идентификация да си общуват с националната схема. Къде в картинката стои и настоящата система за е-автентикация на ДАЕУ, която от временно решение се превръща във все по-устойчиво такова. За щастие всички тези системи „говорят“ (и трябва да говорят според нормативните изисквания) на един „език“ – протоколът SAML 2.0. Но кой кого извиква, с какви параметри, кой какви регистри държи и какво позволява; как се извършва подписване при схеми, които не са националната (напр. чрез съхраняване на SAML 2.0 assertions) и не на последно място – как да бъде осъвременена нормативната уредба с всичко това. Сложни въпроси, които трябва да намерят отговор в следващите 6 месеца, за да не се окажем в батак, в който всичко е толкова фрагментирано, че много малко хора да могат да ползват услугите, които искат със средството за идентификация, което имат.

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

Материалът Как наистина да получим електронна идентификация е публикуван за пръв път на БЛОГодаря.

Creating a CentOS Startup Screen

Post Syndicated from Bozho original https://techblog.bozho.net/creating-a-centos-startup-screen/

When distributing bundled software, you have multiple options, but if we exclude fancy newcomers like Docker and Kubernetes, you’re left with the following options: an installer (for Windows), a package (rpm or deb) for the corresponding distro, tarball with a setup shell script that creates the necessary configurations, and a virtual machine (or virtual appliance).

All of these options are applicable in different scenarios, but distributing a ready-to-deploy virtual machine image is considered standard for enterprise software. Your machine has all the dependencies it needs (because it might not be permitted to connect to the interenet), and it just has to be fired up.

But typically you’d want some initial configuration or at least have the ability to show the users how to connect to your (typically web-based) application. And so creating a startup screen is what many companies choose to do. Below is a simple way to do that on CentOS, which is my distro of preference. (There are other resources on the topic, e.g. this one, but it relies on /etc/inittab which is deprecated in CentOS 8).

useradd startup -m
yum -y install dialog

sed -i -- "s/-o '-p -- \\u' --noclear/--autologin startup --noclear/g" /usr/lib/systemd/system/[email protected]

chmod +x /install/startup.sh
echo "exec /install/startup.sh" >> /home/startup/.bashrc

systemctl daemon-reload

With the code above you are creating a startup user and auto-logging that user in before the regular login prompt. Replacing the Exec like in the [email protected] is doing exactly that.

Then the script adds the invocation of a startup bash script to the .bashrc which gets run when the user is logged in. What this script does is entirely up to you, below is a simple demo using the dialog command (that we just installed above):

#!/bin/sh
# Based on https://askubuntu.com/questions/1705/how-can-i-create-a-select-menu-in-a-shell-script

HEIGHT=15
WIDTH=70
CHOICE_HEIGHT=4
BACKTITLE="Your Company"
TITLE="Your Product setp"
BIND_IP=`ifconfig | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\2/p'`
INFO="Welcome to MyProduct.\n\n\nWeb access URL: https://$BIND_IP\n\n\n\nFor more information visit https://docs.example.com"

CHOICE=$(dialog --clear \
                --backtitle "$BACKTITLE" \
                --title "$TITLE" \
                --msgbox "$INFO" \
                $HEIGHT $WIDTH \
                2>&1 >/dev/tty)

clear
echo 'Enter password for user "root":'
su root

This dialog shows just some basic information, but you can extend it to allow users making choices and input some parameters. More importantly, it gets the current IP address and shows it to the user. That’s not something they can’t do themselves in other ways, but it’s friendlier to show it like that. And you can’t hard-code that, because in each installation it will have a different IP (even if not using DHCP, you should let the user set the static IP that they’ve assigned rather than forcing one on them). At the end of the script it switches to the root user.

Security has to be considered here – your startup user should not be allowed to do anything meaningful in the system, because it is automatically logged in without password. According to this answer exec sort-of solves that problem (e.g. when you mistype the root password, you are back to the startup.sh script rather than to the console).

I agree that’s a rare use-case but I thought I’d share this “arcane” knowledge.

The post Creating a CentOS Startup Screen appeared first on Bozho's tech blog.

Let’s Kill Security Questions

Post Syndicated from Bozho original https://techblog.bozho.net/lets-kill-security-questions/

Let’s kill security questions

Security questions still exist. They are less dominant now, but we haven’t yet condemned them as an industry hard enough so that they stop being added to authentication flows.

But they are bad. They are like passwords, but more easily guessable, because you have a password hint. And while there are opinions that they might be okay in certain scenarios, they have so many pitfalls that in practice we should just not consider them an option.

What are those pitfalls? Social engineering. Almost any security question’s answer is guessable by doing research on the target person online. We share more about our lives and don’t even realize how that affects us security-wise. Many security questions have a limited set of possible answers that can be enumerated with a brute force attack (e.g. what are the most common pet names; what are the most common last names in a given country for a given period of time, in order to guess someone’s mother’s maiden name; what are the high schools in the area where the person lives, and so on). So when someone wants to takeover your account, if all they have to do is open your Facebook profile or try 20-30 options, you have no protection.

But what are they for in the first place? Account recovery. You have forgotten your password and the system asks you some details about you to allow you to reset your password. We already have largely solved the problem of account recovery – send a reset password link to the email of the user. If the system itself is an email service, or in a couple of other scenarios, you can use a phone number, where a one-time password is sent for recovery purposes (or a secondary email, for email providers).

So we have the account recovery problem largely solved, why are security questions still around? Inertia, I guess. And the five monkeys experiment. There is no good reason to have a security question if you can have recovery email or phone. And you can safely consider that to be true (ok, maybe there are edge cases).

There are certain types of account recovery measures that resemble security questions and can be implemented as an additional layer, on top of a phone or email recovery. For more important services (e.g. your Facebook account or your main email), it may not be safe to consider just owning the phone or just having access to the associated email to be enough. Phones get stolen, emails get “broken into”. That’s why a security-like set of questions may serve as additional protection. For example – guessing recent activity. Facebook does that sometimes by asking you about your activity on the site or about your friends. This is not perfect, as it can be monitored by the malicious actor, but is an option. For your email, you can be asked what are the most recent emails that you’ve sent, and be presented with options to choose from, with some made up examples. These things are hard to implement because of geographic and language differences, but “guess your recent activity among these choices”, e.g. dynamically defined security questions, may be an acceptable additional step for account recovery.

But fixed security questions – no. Let’s kill those. I’m not the first to argue against security questions, but we need to be reminded that certain bad security practices should be left in the past.

Authentication is changing. We are desperately trying to get rid of the password itself (and still failing to do so), but before we manage to do so, we should first get rid of the “bad password in disguise”, the security question.

The post Let’s Kill Security Questions appeared first on Bozho's tech blog.

Дигитализацията на публичния сектор с европейски средства става все по-труднa

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

В рамките на националния план за възстановяване и устойчивост дигитализацията на публичния сектор е слабо и откъслечно застъпена. Коментирахме темата с Христо Иванов, Иво Мирчев и Боян Юруков миналата седмица, но ми се ще да развия темата.

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

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

След присъединяването ни към ЕС, има два програмни периода. В първия (2007-2013) програмата за електронно управление е „Административен капацитет“, а във втория (2014-2020) – „Добро управление“. В рамките на тези оперативни програми са предвидени около милиард лева, като немалка част от тях са похарчени (макар реално усвоените по ОПДУ да са около 1/3 в последната година, в която може да се кандидатства за проекти, то остават три години за довършване на проекти и тяхното изплащане).

В рамките на тези два програмни периоди трябваше да сме направили много неща. Обаче не сме. Отчели сме ги проформа, или сме ги изградили системи, които не се използват, или са се използвали, но са изоставени. Или не сме направили неща, които сме обещали, че ще направим. И проблемът е в това, че ЕК няма основание да ни даде трети път пари за същото.

Но нека вляза в конкретика:

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

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

Та от Европейския съюз сме взели вече пари за тези неща. По два пъти за повечето от тях. И затова е трудно те да влязат за трети път в документ, с който искаме пари от Европа. Защото там с право ще кажат „е стига толкова, де, нали вече го правихте това“.

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

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

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

Материалът Дигитализацията на публичния сектор с европейски средства става все по-труднa е публикуван за пръв път на БЛОГодаря.

My Advice To Developers About Working With Databases: Make It Secure

Post Syndicated from Bozho original https://techblog.bozho.net/my-advice-to-developers-about-working-with-databases-make-it-secure/

Last month Ben Brumm asked me for the one advice I’d like to give to developers that are working with databases (in reality – almost all of us). He published mine as well as many others’ answers here, but I’d like to share it with my readers as well.

If I had to give developers working with databases one advice, it would be: make it secure. Every other thing you’ll figure in time – how to structure your tables, how to use ORM, how to optimize queries, how to use indexes, how to do multitenancy. But security may not be on the list of requirements and it may be too late when the need becomes obvious.

So I’d focus on several things:

  • Prevent SQL injections – make sure you use an ORM or prepared statements rather than building queries with string concatenation. Otherwise a malicious actor can inject anything in your queries and turn them into a DROP DATABASE query, or worse – one that exfiltrates all the data.
  • Support encryption in transit – this often has to be supported by the application’s driver configuration, e.g. by trusting a particular server certificate. Unencrypted communication, even within the same datacenter, is a significant risk and that’s why databases support encryption in transit. (You should also think about encryption at rest, but that’s more of an Ops task)
  • Have an audit log at the application level – “who did what” is a very important question from a security and compliance point of view. And no native database functionality can consistently answer the question “who” – it’s the application that manages users. So build an audit trail layer that records who did what changes to what entities/tables.
  • Consider record-level encryption for sensitive data – a database can be dumped in full by those who have access (or gain access maliciously). This is how data breaches happen. Sensitive data (like health data, payment data, or even API keys, secrets or tokens) benefits from being encrypted with an application-managed key, so that access to the database alone doesn’t reveal that data. Another option, often used for credit cards, is tokenization, which shifts the encryption responsibility to the tokenization providers. Managing the keys is hard, but even a basic approach is better than nothing.

Security is often viewed as an “operations” responsibility, and this has lead to a lot of tools that try to solve the above problem without touching the application – web application firewalls, heuristics for database access monitoring, trying to extract the current user, etc. But the application is the right place for many of these protections (although certainly not the only place), and as developers we need to be aware of the risks and best practices.

The post My Advice To Developers About Working With Databases: Make It Secure appeared first on Bozho's tech blog.

Вярно с електронно подписания оригинал

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

Много хора споделят тази снимка: „Вярно с електронно подписания оригинал“.

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

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

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

Обаче… правилните подходи са други:

  • Не се разпечатва. Вече има задължение всички администрации да ползват електронни документи и във вътрешния си оборот, и в комуникация с други администрации. И това е технически възможно и работи. Няма причина да се разпечатва. Разбира се, на малко места е отпаднала хартията, защото какво пише в нормативната уредба и какво става на практика са различни неща.
  • На документа се посочват данни, с които оригиналният документ може да бъде изтеглен. Това предполага авторът да има онлайн система, където да се разполагат документите с адекватен контрол на достъпа. Електронното свидетелство за съдимост е такъв пример – има уеб адрес и код за проверка на оригинала. Тук трябва да се внимава, за да не може злонамерени хора да свалят цялата база с документи, налучквайки идентификаторите им.

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

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

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

Материалът Вярно с електронно подписания оригинал е публикуван за пръв път на БЛОГодаря.

COVID-19 и личната отговорност

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

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

Тук заведенията са пълни, училищата са отворени, а някои болници вече изнемогват; лекари напускат. Много е вероятно само след 10 дни да сме в ситуацията на Чехия (където учебната година започва на 1-ви септември).

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

Българските власти не контролират спазването на ограниченията, не тестват достатъчно, не проследяват адекватно контакти на болни. Не въвеждат онлайн обучение поне за тези над 16г, както други държави.

На този фон, това, което имаме, е личната отговорност и личния пример.

Да носим маски, да ограничим контактите си, ходенето по заведения.

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

Не всеки може да си позволи да си наложи ограничения и затова е важно тези, които можем, да го направим. Важно е и проактивно да докладваме контактите си, ако сме болни, дори да не ни питат (защото често не питат).

Дали такава реакция не е прекалена? Не мисля. Но дори да е, попада в категорията „управление на риска“.

Това може да продължи цяла зима и трябва да се подготвим психически. От сега.

Материалът COVID-19 и личната отговорност е публикуван за пръв път на БЛОГодаря.

Discovering an OSSEC/Wazuh Encryption Issue

Post Syndicated from Bozho original https://techblog.bozho.net/discovering-an-ossec-wazuh-encryption-issue/

I’m trying to get the Wazuh agent (a fork of OSSEC, one of the most popular open source security tools, used for intrusion detection) to talk to our custom backend (namely, our LogSentinel SIEM Collector) to allow us to reuse the powerful Wazuh/OSSEC functionalities for customers that want to install an agent on each endpoint rather than just one collector that “agentlessly” reaches out to multiple sources.

But even though there’s a good documentation on the message format and encryption, I couldn’t get to successfully decrypt the messages. (I’ll refer to both Wazuh and OSSEC, as the functionality is almost identical in both, with the distinction that Wazuh added AES support in addition to blowfish)

That lead me to a two-day investigation on possible reasons. The first side-discovery was the undocumented OpenSSL auto-padding of keys and IVs described in my previous article. Then it lead me to actually writing C code (an copying the relevant Wazuh/OSSEC pieces) in order to debug the issue. With Wazuh/OSSEC I was generating one ciphertext and with Java and openssl CLI – a different one.

I made sure the key, key size, IV and mode (CBC) are identical. That they are equally padded and that OpenSSL’s EVP API is correctly used. All of that was confirmed and yet there was a mismatch, and therefore I could not decrypt the Wazuh/OSSEC message on the other end.

After discovering the 0-padding, I also discovered a mistake in the documentation, which used a static IV of FEDCA9876543210 rather than the one found in the code, where the 0 preceded 9 – FEDCA0987654321. But that didn’t fix the issue either, only got me one step closer.

A side-note here on IVs – Wazuh/OSSEC is using a static IV, which is a bad practice. The issue is reported 5 years ago, but is minor, because they are using some additional randomness per message that remediates the use of a static IV; it’s just not idiomatic to do it that way and may have unexpected side-effects.

So, after debugging the C code, I got to a simple code that could be used to reproduce the issue and asked a question on Stackoverflow. 5 minutes after posting the question I found another, related question that had the answer – using hex strings like that in C doesn’t work. Instead, they should be encoded: char *iv = (char *)"\xFE\xDC\xBA\x09\x87\x65\x43\x21\x00\x00\x00\x00\x00\x00\x00\x00";. So, the value is not the bytes corresponding to the hex string, but the ASCII codes of each character in the hex string. I validated that in the receiving Java end with this code:

This has an implication on the documentation, as well as on the whole scheme as well. Because the Wazuh/OSSEC AES key is: MD5(password) + MD5(MD5(agentName) + MD5(agentID)){0, 15}, the 2nd part is practically discarded, because the MD5(password) is 32 characters (= 32 ASCII codes/bytes), which is the length of the AES key. This makes the key derived from a significantly smaller pool of options – the permutations of 16 bytes, rather than of 256 bytes.

I raised an issue with Wazuh. Although this can be seen as a vulnerability (due to the reduced key space), it’s rather minor from security point of view, and as communication is mostly happening within the corporate network, I don’t think it has to be privately reported and fixed immediately.

Yet, I made a recommendation for introducing an additional configuration option to allow to transition to the updated protocol without causing backward compatibility issues. In fact, I’d go further and recommend using TLS/DTLS rather than a home-grown, AES-based scheme. Mutual authentication can be achieved through TLS mutual authentication rather than through a shared secret.

It’s satisfying to discover issues in popular software, especially when they are not written in your “native” programming language. And as a rule of thumb – encodings often cause problems, so we should be extra careful with them.

The post Discovering an OSSEC/Wazuh Encryption Issue appeared first on Bozho's tech blog.

OpenSSL Key and IV Padding

Post Syndicated from Bozho original https://techblog.bozho.net/openssl-key-and-iv-padding/

OpenSSL is an omnipresent tool when it comes to encryption. While in Java we are used to the native Java implementations of cryptographic primitives, most other languages rely on OpenSSL.

Yesterday I was investigating the encryption used by one open source tool written in C, and two things looked strange: they were using a 192 bit key for AES 256, and they were using a 64-bit IV (initialization vector) instead of the required 128 bits (in fact, it was even a 56-bit IV).

But somehow, magically, OpenSSL didn’t complain the way my Java implementation did, and encryption worked. So, I figured, OpenSSL is doing some padding of the key and IV. But what? Is it prepending zeroes, is it appending zeroes, is it doing PKCS padding or ISO/IEC 7816-4 padding, or any of the other alternatives. I had to know if I wanted to make my Java counterpart supply the correct key and IV.

It was straightforward to test with the following commands:

# First generate the ciphertext by encrypting input.dat which contains "testtesttesttesttesttest"
$ openssl enc -aes-256-cbc -nosalt -e -a -A -in input.dat -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321' -out input-test.enc

# Then test decryption with the same key and IV
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
testtesttesttesttesttest

# Then test decryption with different paddings
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA9876543210'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c760' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76000' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '07c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
bad decrypt

So, OpenSSL is padding keys and IVs with zeroes until they meet the expected size. Note that if -aes-192-cbc is used instead of -aes-256-cbc, decryption will fail, because OpenSSL will pad it with fewer zeroes and so the key will be different.

Not an unexpected behavaior, but I’d prefer it to report incorrect key sizes rather than “do magic”, especially when it’s not easy to find exactly what magic it’s doing. I couldn’t find it documented, and the comments to this SO question hint in the same direction. In fact, for plaintext padding, OpenSSL uses PKCS padding (which is documented), so it’s extra confusing that it’s using zero-padding here.

In any case, follow the advice from the stackoverflow answer and don’t rely on this padding – always provide the key and IV in the right size.

The post OpenSSL Key and IV Padding appeared first on Bozho's tech blog.

Как да разкараме печатите от медицинските изследвания за прием в ясла

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

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

Ще коментирам обаче изследванията, и по-точно – удостоверяването на тяхната автентичност. Направихме всички изследвания, разпечатахме резултата от сайта на лабораторията, и ги занесохме заедно с другите документи. Само че – проблем. Трябвало да имат печати. Жена ми се разходи до лабораторията, сложиха ѝ един печат, обаче и това не беше достатъчно – трябвало да има втори, правоъгълен печат. Не можело да го приемат без него. Винаги бил така. А правоъгълният печат го имало само в централата на лабораторията – в другия край на града.

Попитах кой и защо го изисква – оказа се РЗИ (Столичната регионална здравна инспекция). Проведох около 15 разговора с 5-6 различни хора в РЗИ, изчетох приложимата нормативна уредба (Наредба 26, Наредба 3, и общо взето заключих три неща:

  • Това не е работа на никого. Може би на инспекторите.
  • Няма нормативно основание за изискване на печати
  • Могат да глобят яслата, ако няма печати, защото „разбира се, че ще ви върнат, като нямате печат“

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

Така че предприех следните мерки:

  • Писмо до Министерство на здравеопазването с предложения за нормативно уреждане на автентичността на медицински изследвания
  • Писмо до РЗИ да прекратят незаконосъобразните си практики
  • Писмо до Столична община, да установи ясни изисквания към детските ясли относно реквизитите на документи, които изискват

Целта е да има законосъобразни правила, директорите на яслите и инспекторите на РЗИ да знаят какви са правилата, а не да си ги измислят на място или да правят „както винаги са правили“, без да има нормативно основание за това.

Писмата до РЗИ и Столична община са скучни, но ще приложа писмото до Министерство на образованието, защото там са реалните предложения за промяна. Както сподели един от хората в РЗИ, съществува проблем с фалшиви изследвания, и „декларациите не работят“ (на моето предложение да спазват административнопроцесуалния кодекс и да приемат декларация за истинност на изследванията):

Чл. 43. Административният орган не може да откаже приемане на писмена декларация, с която се установяват факти и обстоятелства, за които специален закон не предвижда доказване по определен начин или с определени средства. [..]

Писмото до министъра изисква единствено нормативни изменения – с изключение на ал. 3, т. 3, останалите варианти са налице и в момента. Използването на електронни печати е по принцип правилния подход в дългосрочен план, но изисква надграждане на системи.

Уважаеми г-н Министър,

Във връзка с неписано правило Столичната РЗИ да изисква два различни печата върху изследвания за приемане на деца (по реда на чл. 20 от Наредба 26 от 18.11.2008 за устройството на дейността на детските ясли и детските кухни и здравните изисквания към тях), и отчитайки:
1. Голямото неудобство за родители в това да бъдат куриери на администрацията и в 21-ви век да обикалят за различни видове печати, особено в контекста на пандемия.
2. Риска от предоставяне на фалшиви изследвания
3. Факта, че повечето лаборатории имат онлайн системи за предоставяне на резултатите от изследвания
4. Усилията за въвеждане на електронно здравеопазване

бих искал да предложа следното изменение на Наредба 26:

В чл. 20 се създават нови алинеи 3-5:
(3) Автентичността на изследванията по ал. 1, т.3-5 се удостоверява от лабораторията, извършила изследването, по един от следните начини:
1. чрез възможност за проверка с телефонно обаждане на база на уникален идентификатор на изследването. Телефон за контакт и номер на изследването трябва да са посочени в документа с резултатите.
2. чрез предоставяне от страна на родителите на данни за достъп до онлайн система за проверка на резултата
3. чрез електронен печат на лабораторията върху електронен документ с резултатите, по смисъла на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета от 23 юли 2014 г. относно електронната идентификация и удостоверителните услуги при електронни трансакции на вътрешния пазар и за отмяна на Директива 1999/93/ЕО (ОВ, L 257/73 от 28 август 2014 г.)
3.
(4) Резултатите от изследванията по ал. 1, т.3-5 се приемат на хартиен носител и по електронен път, на адрес на електронна поща или чрез системата за сигурно електронно връчване по смисъла на § 1, т. 31 от допълнителните разпоредби на Закона за електронното управление.
(5) Резултатите от изследванията по ал. 1, т.3-5 се съхраняват за срок от 12 месеца, след което се унищожават.

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

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

С уважение,
Божидар Божанов

В по-общ смисъл, за цялата драма с печатите преди време бях подготвил изменение на Административнопроцесуалния кодекс, с която да се забрани изискването на печати:

„§ 1а. (1) Във връзка с административното обслужване на гражданите и юридическите лица административните органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги не могат да изискват полагане на печат върху документ на хартиен носител за удостоверяване на авторството.
(2) Авторството на документ по ал. 1 се удостоверява от неговия издател чрез саморъчен подпис. Документът съдържа информация за имената на лицето, което го е издало, качеството и длъжността, в които действа, както и основанието на неговата представителна власт.
(3) Органите, лицата и организациите по ал. 1 не могат да отказват приемане на документ от граждани и юридически поради липса на поставен печат.
(4) За неизпълнение на задълженията по ал. 1 и 3 на отговорните длъжностни лица се налага административнонаказателна санкция по чл. 305 от Административнопроцесуалния кодекс.“

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

Защо се занимавам с нещо толкова дребно? Нали вече записахме детето, повече едва ли ще имаме тоя проблем?

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

Материалът Как да разкараме печатите от медицинските изследвания за прием в ясла е публикуван за пръв път на БЛОГодаря.

ElasticSearch Multitenancy With Routing

Post Syndicated from Bozho original https://techblog.bozho.net/elasticsearch-multitenancy-with-routing/

Elasticsearch is great, but optimizing it for high load is always tricky. This won’t be yet another “Tips and tricks for optimizing Elasticsearch” article – there are many great ones out there. I’m going to focus on one narrow use-case – multitenant systems, i.e. those that support multiple customers/users (tenants).

You can build a multitenant search engine in three different ways:

  • Cluster per tenant – this is the hardest to manage and requires a lot of devops automation. Depending on the types of customers it may be worth it to completely isolate them, but that’s rarely the case
  • Index per tenant – this can be fine initially, and requires little additional coding (you just parameterize the “index” parameter in the URL of the queries), but it’s likely to cause problems as the customer base grows. Also, supporting consistent mappings and settings across indexes may be trickier than it sounds (e.g. some may reject an update and others may not depending on what’s indexed). Moving data to colder indexes also becomes more complex.
  • Tenant-based routing – this means you put everything in one cluster but you configure your search routing to be tenant-specific, which allows you to logically isolate data within a single index.

The last one seems to be the preferred option in general. What is routing? The Elasticsearch blog has a good overview and documentation. The idea lies in the way Elasticsearch handles indexing and searching – it splits data into shards (each shard is a separate Lucene index and can be replicated on more than one node). A shard is a logical grouping within a single Elasticsearch node. When no custom routing is used, and an index request comes, the ID is used to determine which shard is going to be used to store the data. However, during search, Elasticsearch doesn’t know which shards have the data, so it has ask multiple shards and gather the results. Related to that, there’s the newly introduced adaptive replica selection, where the proper shard replica is selected intelligently, rather than using round-robin.

Custom routing allows you to specify a routing value when indexing a document and then a search can be directed only to the shard that has the same routing value. For example, at LogSentinel when we index a log entry, we use the data source id (applicationId) for routing. So each application (data source) that generates logs has a separate identifier which allows us to query only that data source’s shard. That way, even though we may have a thousand clients with a hundred data sources each, a query will be precisely targeted to where the data for that particular customer’s data source lies.

This is key for horizontally scaling multitenant applications. When there’s terabytes of data and billions of documents, many shards will be needed (in order to avoid large and heavy shards that cause performance issues). Finding data in this haystack requires the ability to know where to look.

Note that you can (and probably should) make routing required in these cases – each indexed document must be required to have a routing key, otherwise an implementation oversight may lead to a slow index.

Using custom routing you are practically turning one large Elasticsearch cluster into smaller sections, logically separated based on meaningful identifiers. In our case, it is not a userId/customerId, but one level deeper – there are multiple shards per customer, but depending on the use-case, it can be one shard per customer, using the userId/customerId. Using more than one shard per customer may complicate things a little – for example having too many shards per customer may require searches that span too many shards, but that’s not necessarily worse than not using routing.

There are some caveats – the isolation of customer data has to be handled in the application layer (whereas for the first two approaches data is segregated operationally). If there’s an application bug or lack of proper access checks, one user can query data from other users’ shards by specifying their routing key. It’s the role of the application in front of Elasticsearch to only allow queries with routing keys belonging to the currently authenticated user.

There are cases when the first two approaches to multitenancy are viable (e.g. a few very large customers), but in general the routing approach is the most scalable one.

The post ElasticSearch Multitenancy With Routing appeared first on Bozho's tech blog.

Is It Really Two-Factor Authentication?

Post Syndicated from Bozho original https://techblog.bozho.net/is-it-really-two-factor-authentication/

Terminology-wise, there is a clear distinction between two-factor authentication (multi-factor authentication) and two-step verification (authentication), as this article explains. 2FA/MFA is authentication using more than one factors, i.e. “something you know” (password), “something you have” (token, card) and “something you are” (biometrics). Two-step verification is basically using two passwords – one permanent and another one that is short-lived and one-time.

At least that’s the theory. In practice it’s more complicated to say which authentication methods belongs to which category (“something you X”). Let me illustrate that with a few emamples:

  • An OTP hardware token is considered “something you have”. But it uses a shared symmetric secret with the server so that both can generate the same code at the same time (if using TOTP), or the same sequence. This means the secret is effectively “something you know”, because someone may steal it from the server, even though the hardware token is protected. Unless, of course, the server stores the shared secret in an HSM and does the OTP comparison on the HSM itself (some support that). And there’s still a theoretical possibility for the keys to leak prior to being stored on hardware. So is a hardware token “something you have” or “something you know”? For practical purposes it can be considered “something you have”
  • Smartphone OTP is often not considered as secure as a hardware token, but it should be, due to the secure storage of modern phones. The secret is shared once during enrollment (usually with on-screen scanning), so it should be “something you have” as much as a hardware token
  • SMS is not considered secure and often given as an example for 2-step verification, because it’s just another password. While that’s true, this is because of a particular SS7 vulnerability (allowing the interception of mobile communication). If mobile communication standards were secure, the SIM card would be tied to the number and only the SIM card holder would be able to receive the message, making it “something you have”. But with the known vulnerabilities, it is “something you know”, and that something is actually the phone number.
  • Fingerprint scanners represent “something you are”. And in most devices they are built in a way that the scanner authenticates to the phone (being cryptographically bound to the CPU) while transmitting the fingerprint data, so you can’t just intercept the bytes transferred and then replay them. That’s the theory; it’s not publicly documented how it’s implemented. But if it were not so, then “something you are” is “something you have” – a sequence of bytes representing your fingerprint scan, and that can leak. This is precisely why biometric identification should only be done locally, on the phone, without any server interaction – you can’t make sure the server is receiving sensor-scanned data or captured and replayed data. That said, biometric factors are tied to the proper implementation of the authenticating smartphone application – if your, say, banking application needs a fingerprint scan to run, a malicious actor should not be able to bypass that by stealing shared credentials (userIDs, secrets) and do API calls to your service. So to the server there’s no “something you are”. It’s always “something that the client-side application has verified that you are, if implemented properly”
  • A digital signature (via a smartcard or yubikey or even a smartphone with secure hardware storage for private keys) is “something you have” – it works by signing one-time challenges, sent by the server and verifying that the signature has been created by the private key associated with the previously enrolled public key. Knowing the public key gives you nothing, because of how public-key cryptography works. There’s no shared secret and no intermediary whose data flow can be intercepted. A private key is still “something you know”, but by putting it in hardware it becomes “something you have”, i.e. a true second factor. Of course, until someone finds out that the random generation of primes used for generating the private key has been broken and you can derive the private key form the public key (as happened recently with one vendor).

There isn’t an obvious boundary between theoretical and practical. “Something you are” and “something you have” can eventually be turned into “something you know” (or “something someone stores”). Some theoretical attacks can become very practical overnight.

I’d suggest we stick to calling everything “two-factor authentication”, because it’s more important to have mass understanding of the usefulness of the technique than to nitpick on the terminology. 2FA does not solve phishing, unfortunately, but it solves leaked credentials, which is good enough and everyone should have some form of it. Even SMS is better than nothing (obviously, for high-profile systems, digital signatures is the way to go).

The post Is It Really Two-Factor Authentication? appeared first on Bozho's tech blog.