Tag Archives: dp

Достъп до лични данни за целите на разследване на престъпления

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/10/07/courteu_58-2002/

Стана известно решението на Съда на ЕС по дело C‑207/16 с предмет преюдициално запитване   от Audiencia Provincial de Tarragona (съд на провинция Тарагона, Испания)   в рамките на производство по дело, образувано по протест на испанското Министерство на финансите по повод разрешаването на достъп на съдебната полиция до лични данни, запазени от доставчици на електронни съобщителни услуги.

Решението  по дело C-207/16 Ministerio Fiscal е част от юриспруденцията относно член 15, който в общи линии позволява на държавите-членки да разрешават намеса в тайната на кореспонденцията при определени обстоятелства, виж и  Digital Rights Ireland (C-293/12 и 594/12), Tele2 / Watson (Joined Cases C-203/15 и C-698/15).

Държавите-членки могат да приемат законодателни мерки, за да ограничат обхвата на правата и задълженията, предвидени в член 5, член 6, член 8, параграф 1, 2, 3, и 4 и член 9 от настоящата директива, когато такова ограничаване представлява необходима, подходяща и пропорционална мярка в рамките на демократично общество, за да гарантира национална сигурност (т.е държавна сигурност), отбрана, обществена безопасност и превенцията, разследването, разкриването и преследването на престъпления или неразрешено използване на електронна комуникационна система, както е посочено в член 13, параграф 1 от Директива 95/46/ЕО. […]

 

Фактите

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

Съдът отказва – защото 1) исканата мярка не била пригодна за разкриване на извършителите на престъплението и 2) според закона това може да се извършва при тежки престъпления. Съгласно испанския наказателен кодекс тежки били престъпленията, които се наказват с лишаване от свобода над пет години — а разглежданите в главното производство деяния не съставляват такова престъпление. Прокуратурата протестира това определение пред запитващата юрисдикция. Според нея предоставянето на разглежданите данни е трябвало да бъде разрешено поради естеството на деянията.

Въпросите

 1)   Може ли достатъчната тежест на престъплението като критерий, обосноваващ засягането на признатите в членове 7 и 8 от [Хартата] основни права, да се определи единствено с оглед на наказанието, което може да се наложи за разследваното престъпление, или е необходимо освен това да се установи, че с престъпното деяние се увреждат в особена степен индивидуални и/или колективни правни интереси?

2)      Евентуално, ако определянето на тежестта на престъплението с оглед единствено на наказанието, което може да се наложи, отговаря на конституционните принципи на Съюза, приложени от Съда на ЕС в решението му [от 8 април 2014 г., Digital Rights Ireland и др., C‑293/12 и C‑594/12, EU:C:2014:238] като критерии за строг контрол на Директива [2002/58], то какъв следва да е минималният праг за наказанието? Допустимо ли е по общ начин да се предвиди праг от три години лишаване от свобода?“.

Решението

Достъпът на публичните органи до такива данни съставлява намеса в основното право на зачитане на личния живот, закрепено в член 7 от Хартата. Такъв достъп представлява и намеса в основното право на защита на личните данни, гарантирано в член 8 от Хартата, тъй като представлява обработка на лични данни.

Когато  намесата, до която води такъв достъп, не е тежка, този достъп може да бъде обоснован от целта за превенция, разследване, разкриване и преследване общо на „[престъпления]“. [57]

Достъпът само до данните, посочени в разглежданото в главното производство искане, не може да бъде квалифициран като „тежка“ намеса в основните права на лицата [61]

Намесата, до която води достъп до такива данни, може следователно да бъде обоснована от целта за превенция, разследване, разкриване и преследване общо на „[престъпления]“, посочена в член 15, параграф 1, първо изречение от Директива 2002/58, без да е необходимо тези престъпления да са квалифицирани като „тежки“.[62]

В същия смисъл е и Заключението на Генералния адвокат:

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

Коментар на проф. Лорна Удс

ЕСПЧ: Big Brother Watch

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/09/25/%D0%B5%D1%81%D0%BF%D1%87-big-brother-watch/

Стана известно решението на ЕСПЧ по делото Big Brother Watch and Others v. the United Kingdom.

Нарушение на чл.8 и чл.10 ЕКПЧ.

Жалбите са предизвикани от информацията, разкрита от Едуард Сноудън, за съществуването на програми за наблюдение и обмен на разузнавателни данни, управлявани от разузнавателните служби на САЩ и Обединеното кралство. По-конкретно,  че  електронни съобщения и / или съобщителни данни е вероятно да бъдат задържани или получени от разузнавателните служби на Обединеното кралство, разчитащи на режима, установен в британския закон RIPA. Бяха подчертани три области на проблемите: прихващане, споделяне и достъп до комуникации.  Във всички случаи жалбоподателите смятат, че защитата срещу злоупотребите е недостатъчна и че режимите не са нито законни, нито необходими в едно демократично общество.

Жалбоподателите твърдят, че  режимът не е законосъобразен,  значимите елементи на режима не са били публично оповестени и  не отговарят на  изискванията по решението  Вебер.

Шестте принципа, установени във Weber and Saravia (app no. 54934/00)   са отправна точка за изводите:

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

Според ЕСПЧ към изискванията по решението Вебер трябва да се прибавят и съображенията на Голямата камара по Zakharov (app no. 47143/06).

Накрая, ЕСПЧ се позовава на  правото на ЕС – по-специално на решенията Digital Rights Ireland (дело C-293/12 и C-594/12) и Watson (дело C-698/15) –  прихващането е само за целите на борбата с тежките престъпления  и   този достъп подлежи на предварителен преглед (разрешение) от съд или независим административен орган. 
 В решението на ЕСПЧ, освен липса на нужните гаранции по чл.8,  е взето предвид, че става дума за проследяване на журналисти -по тази причина  има и аргумент по чл.10, свобода на изразяване. Прилагането на мерките не може да се разглежда в съответствие със закона за целите на чл.  10 ЕКПЧ.

Най-важните фрагменти от решението според  EJIL

Измененията на Закона за защита на личните данни по GDPR – внесени в парламента

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/07/19/zzld/

От сайта на парламента –

Законопроект за изменение и допълнение на Закона за защита на личните данни

Както ще установите,  с пар. 25 и следващите се предлагат изменения в десетки други закони.  В голяма част от тях препратката към Закона за защита на личните данни се заменя с  „изискванията за тяхната защита“, но в някои закони има и по-обстойни промени.

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

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

Целите на проекта са описани така:

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

Какво съдържа проектът:

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

и в частност:

Актуализиран понятиен апарат: Регламентът значително разширява досегашния понятиен апарат в областта на защитата на личните данни. С предлаганите законодателни промени използваната терминология се актуализира в съответствие с Регламент 2016/679 и Директива 2016/680.

Регистрация на администратори: от 25 май 2018 г. отпада задължението за регистрация на администраторите на лични данни в Комисията за защита на личните данни. Това обстоятелство е отчетено в проекта на законови изменения и допълнения, като е предложено отменяне на досегашните текстове, уреждащи задължителната регистрация като администратор на лични данни.

Особени ситуации на обработване на лични данни: законопроектът предлага по-детайлно регламентиране на отделни групи обществени отношения, като упражняването на правото на свобода на изразяване и информация, включително за журналистически цели и за целите на академичното, художественото или литературното изразяване; обработване на лични данни в контекста на трудови/служебни правоотношения; законово регламентиране в специални закони на публичния достъп до ЕГН; изключване на данните на починали лица от кръга на личните данни.

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

Подзаконова уредба: с оглед на голямото разнообразие на материята, уредена с Общия регламент, съответно със ЗЗЛД, в предложените промени е предвидена законодателна делегация за приемане на подзаконови актове, като наредба в областта на сертифицирането, както и ненормативни документи, като например минималните изисквания при систематично мащабно видеонаблюдение на публично достъпни зони, както и по отношение на автоматизираното вземане на индивидуални решения, включително профилиране.

Съд на ЕС: Свидетели на Йехова и лични данни

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/07/11/dp-24/

Стана известно решението на Съда на ЕС по дело C‑25/17 с предмет преюдициално запитване, отправено на основание член 267 ДФЕС от Korkein hallinto-oikeus (Върховен административен съд, Финландия).

Комисията за защита на данните във Финландия постановява решение, с което забранява на религиозната общност „Свидетели на Йехова“ да събира или да обработва лични данни при извършваната от членовете ѝ проповедническа дейност „от врата на врата“, доколкото не са изпълнени законовите изисквания за обработването на такива данни. Освен това  Комисията за защита на данните задължава тази общност да направи в шестмесечен срок необходимото, за да гарантира, че за нейните цели лични данни няма да се събират в нарушение на тези изисквания.

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

Религиозната организация обжалва.  Съдът решава да спре производството и да постави на Съда следните преюдициални въпроси:

„1)      Трябва ли изключенията от приложното поле на Директива [95/46], посочени в член 3, параграф 2, първо и второ тире, да се тълкуват в смисъл, че събирането и другите видове обработка на лични данни, които членовете на дадена религиозна общност извършват във връзка с осъществяваната проповедническа дейност „от врата на врата“, не попадат в приложното поле на Директивата? Какво значение при преценката на приложимостта на Директива [95/46] имат, от една страна, обстоятелството, че проповедническата дейност, във връзка с която се събират данните, се организира от религиозната общност и от нейните сборове, и от друга страна, обстоятелството, че едновременно с това става дума и за изповядване на религия лично от членовете на религиозната общност?

2)      Като се отчитат съображения 26 и 27 от Директива [95/46], трябва ли определението на понятието „файл“ в член 2, буква в) от Директивата да се тълкува в смисъл, че съвкупността от лични данни, които се събират с неавтоматични средства във връзка с описаната по-горе проповедническа дейност „от врата на врата“ (име и адрес, както и други възможни данни и характеристики, отнасящи се до лицето),

a)      не представлява такъв файл, тъй като не става въпрос за специфични картотеки или списъци или други подобни класификационни системи по смисъла на определението в [Закон № 523/1999];

б)      представлява такъв файл, тъй като от данните предвид тяхното предназначение на практика е възможно лесно и без неоправдани разходи да бъде извлечена необходимата за по-нататъшно ползване информация, както е предвидено в [Закон № 523/1999]?

3)      Трябва ли изразът в член 2, буква г) от Директива [95/46] „който сам или съвместно с други определя целите и средствата на обработка на лични данни“ да се тълкува в смисъл, че религиозна общност, организираща дейност, при която се събират лични данни (в това число чрез определянето на радиуса на действие на проповедниците, чрез проследяването на проповедническата дейност и поддържането на регистри на лицата, които не желаят да бъдат посещавани от проповедници), може да бъде разглеждана като администратор на лични данни по отношение на тази дейност на нейните членове, въпреки твърдението на религиозната общност, че само отделните проповедници имат достъп до записаната информация?

4)      Трябва ли член 2, буква г) от Директива [95/46] да се тълкува в смисъл, че религиозната общност може да се класифицира като администратор само когато предприема други специфични мерки, като нареждания или писмени указания, с които управлява събирането на данни, или е достатъчно религиозната общност фактически да играе роля при управлението на дейността на членовете си?

Решението

1 Както следва от член 1, параграф 1 и от съображение 10 от Директива 95/46, нейната цел е да се гарантира висока степен на защита на основните права и свободи на физическите лица, и в частност на правото им на личен живот при обработването на лични данни (решение от 13 май 2014 г., Google Spain и Google, C‑131/12, EU:C:2014:317, т. 66 и от 5 юни 2018 г., Wirtschaftsakademie Schleswig-Holstein, C‑210/16, EU:C:2018:388, т. 26).

Макар извършваната от членове на религиозна общност проповедническа дейност „от врата на врата“ да е по този начин защитена с член 10, параграф 1 от Хартата като израз на вярата на проповедника или проповедниците, това обстоятелство не придава на тази дейност характер на изцяло лично или домашно занимание по смисъла на член 3, параграф 2, второ тире от Директива 95/46. Проповедническата дейност излиза извън личната сфера на проповядващите членове на дадена религиозна общност.

С оглед на гореизложените съображения на първия въпрос следва да се отговори, че член 3, параграф 2 от Директива 95/46, разглеждан във връзка с член 10, параграф 1 от Хартата, трябва да се тълкува в смисъл, че събирането на лични данни, извършвано от членове на религиозна общност при проповедническата им дейност „от врата на врата“, и по-нататъшното обработване на тези данни не представляват нито обработване на лични данни при извършване на дейности, посочени в член 3, параграф 2, първо тире от тази директива, нито обработване на лични данни, извършвано от физически лица в хода на изцяло лични или домашни занимания по смисъла на член 3, параграф 2, второ тире от същата директива. [51]

2 Относно понятието файл – директивата определя широко понятието „файл“, по-специално визирайки „всеки“ структуриран набор от лични данни.

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

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

ЕНОЗД: Неприкосновеност на личния живот by design – становище 5/2018

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/06/07/esdp/

Публикувано е становище 5/2018 на Европейския надзорен орган за защита на данните (ЕНОЗД).

Становището е посветено на концепцията Privacy by design.

В началото на 2018 г. публичният дебат за обработката на лични данни  достигна безпрецедентно ниво на внимание, се казва в становището. Целта е да се разбере как  личните данни  се обработват и използват за проследяване на дейностите на гражданите в мрежата.  Въпреки огромния медиен интерес обществеността все още знае само за “върха на айсберга” по отношение на проследяването. 
ЕНОЗД вече анализира използването на лични данни за онлайн манипулиране  в неотдавнашното си становище и предостави препоръки.  Настоящото становище прави преглед на правните и технологичните постижения  в разглежданата област и дава препоръки за мерки, които допълнително ще подобрят защитата на личните данни и защитата на данните  by design.
Терминът означава  широка концепция за технологични мерки за осигуряване на неприкосновеност на личния живот.

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/756489/rss

Security updates have been issued by CentOS (procps, xmlrpc, and xmlrpc3), Debian (batik, prosody, redmine, wireshark, and zookeeper), Fedora (jasper, kernel, poppler, and xmlrpc), Mageia (git and wireshark), Red Hat (rh-java-common-xmlrpc), Slackware (git), SUSE (bzr, dpdk-thunderxdpdk, and ocaml), and Ubuntu (exempi).

AWS Resources Addressing Argentina’s Personal Data Protection Law and Disposition No. 11/2006

Post Syndicated from Leandro Bennaton original https://aws.amazon.com/blogs/security/aws-and-resources-addressing-argentinas-personal-data-protection-law-and-disposition-no-112006/

We have two new resources to help customers address their data protection requirements in Argentina. These resources specifically address the needs outlined under the Personal Data Protection Law No. 25.326, as supplemented by Regulatory Decree No. 1558/2001 (“PDPL”), including Disposition No. 11/2006. For context, the PDPL is an Argentine federal law that applies to the protection of personal data, including during transfer and processing.

A new webpage focused on data privacy in Argentina features FAQs, helpful links, and whitepapers that provide an overview of PDPL considerations, as well as our security assurance frameworks and international certifications, including ISO 27001, ISO 27017, and ISO 27018. You’ll also find details about our Information Request Report and the high bar of security at AWS data centers.

Additionally, we’ve released a new workbook that offers a detailed mapping as to how customers can operate securely under the Shared Responsibility Model while also aligning with Disposition No. 11/2006. The AWS Disposition 11/2006 Workbook can be downloaded from the Argentina Data Privacy page or directly from this link. Both resources are also available in Spanish from the Privacidad de los datos en Argentina page.

Want more AWS Security news? Follow us on Twitter.

 

За едно дарение

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

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

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

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

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

Когато журналист от Дневник ме пита „Защо го дарявате“, отговорът ми беше „Защо не?“. Така или иначе сме отделили достатъчно време да помагаме на държавата за електронното управление, не само докато бяхме в Министерски съвет, но и преди и след това, така че беше съвсем логично да помогнем и не само с мнения и документи, а и с това, което разработваме. Нямам намерение да участвам в обществени поръчки, които и да спечеля честно, винаги ще оставят съмнения, че са били наредени – хората до голяма степен с право имат негативни очаквания, че „и тоя си постла да намаже от държавния пост“. Това не е случаят и не искахме да има никакви съмнения по въпроса. Основният ни пазар е частният сектор, не обществените поръчки.

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

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

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

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

Amazon SageMaker Updates – Tokyo Region, CloudFormation, Chainer, and GreenGrass ML

Post Syndicated from Randall Hunt original https://aws.amazon.com/blogs/aws/sagemaker-tokyo-summit-2018/

Today, at the AWS Summit in Tokyo we announced a number of updates and new features for Amazon SageMaker. Starting today, SageMaker is available in Asia Pacific (Tokyo)! SageMaker also now supports CloudFormation. A new machine learning framework, Chainer, is now available in the SageMaker Python SDK, in addition to MXNet and Tensorflow. Finally, support for running Chainer models on several devices was added to AWS Greengrass Machine Learning.

Amazon SageMaker Chainer Estimator


Chainer is a popular, flexible, and intuitive deep learning framework. Chainer networks work on a “Define-by-Run” scheme, where the network topology is defined dynamically via forward computation. This is in contrast to many other frameworks which work on a “Define-and-Run” scheme where the topology of the network is defined separately from the data. A lot of developers enjoy the Chainer scheme since it allows them to write their networks with native python constructs and tools.

Luckily, using Chainer with SageMaker is just as easy as using a TensorFlow or MXNet estimator. In fact, it might even be a bit easier since it’s likely you can take your existing scripts and use them to train on SageMaker with very few modifications. With TensorFlow or MXNet users have to implement a train function with a particular signature. With Chainer your scripts can be a little bit more portable as you can simply read from a few environment variables like SM_MODEL_DIR, SM_NUM_GPUS, and others. We can wrap our existing script in a if __name__ == '__main__': guard and invoke it locally or on sagemaker.


import argparse
import os

if __name__ =='__main__':

    parser = argparse.ArgumentParser()

    # hyperparameters sent by the client are passed as command-line arguments to the script.
    parser.add_argument('--epochs', type=int, default=10)
    parser.add_argument('--batch-size', type=int, default=64)
    parser.add_argument('--learning-rate', type=float, default=0.05)

    # Data, model, and output directories
    parser.add_argument('--output-data-dir', type=str, default=os.environ['SM_OUTPUT_DATA_DIR'])
    parser.add_argument('--model-dir', type=str, default=os.environ['SM_MODEL_DIR'])
    parser.add_argument('--train', type=str, default=os.environ['SM_CHANNEL_TRAIN'])
    parser.add_argument('--test', type=str, default=os.environ['SM_CHANNEL_TEST'])

    args, _ = parser.parse_known_args()

    # ... load from args.train and args.test, train a model, write model to args.model_dir.

Then, we can run that script locally or use the SageMaker Python SDK to launch it on some GPU instances in SageMaker. The hyperparameters will get passed in to the script as CLI commands and the environment variables above will be autopopulated. When we call fit the input channels we pass will be populated in the SM_CHANNEL_* environment variables.


from sagemaker.chainer.estimator import Chainer
# Create my estimator
chainer_estimator = Chainer(
    entry_point='example.py',
    train_instance_count=1,
    train_instance_type='ml.p3.2xlarge',
    hyperparameters={'epochs': 10, 'batch-size': 64}
)
# Train my estimator
chainer_estimator.fit({'train': train_input, 'test': test_input})

# Deploy my estimator to a SageMaker Endpoint and get a Predictor
predictor = chainer_estimator.deploy(
    instance_type="ml.m4.xlarge",
    initial_instance_count=1
)

Now, instead of bringing your own docker container for training and hosting with Chainer, you can just maintain your script. You can see the full sagemaker-chainer-containers on github. One of my favorite features of the new container is built-in chainermn for easy multi-node distribution of your chainer training jobs.

There’s a lot more documentation and information available in both the README and the example notebooks.

AWS GreenGrass ML with Chainer

AWS GreenGrass ML now includes a pre-built Chainer package for all devices powered by Intel Atom, NVIDIA Jetson, TX2, and Raspberry Pi. So, now GreenGrass ML provides pre-built packages for TensorFlow, Apache MXNet, and Chainer! You can train your models on SageMaker then easily deploy it to any GreenGrass-enabled device using GreenGrass ML.

JAWS UG

I want to give a quick shout out to all of our wonderful and inspirational friends in the JAWS UG who attended the AWS Summit in Tokyo today. I’ve very much enjoyed seeing your pictures of the summit. Thanks for making Japan an amazing place for AWS developers! I can’t wait to visit again and meet with all of you.

Randall

Monitoring your Amazon SNS message filtering activity with Amazon CloudWatch

Post Syndicated from Rachel Richardson original https://aws.amazon.com/blogs/compute/monitoring-your-amazon-sns-message-filtering-activity-with-amazon-cloudwatch/

This post is courtesy of Otavio Ferreira, Manager, Amazon SNS, AWS Messaging.

Amazon SNS message filtering provides a set of string and numeric matching operators that allow each subscription to receive only the messages of interest. Hence, SNS message filtering can simplify your pub/sub messaging architecture by offloading the message filtering logic from your subscriber systems, as well as the message routing logic from your publisher systems.

After you set the subscription attribute that defines a filter policy, the subscribing endpoint receives only the messages that carry attributes matching this filter policy. Other messages published to the topic are filtered out for this subscription. In this way, the native integration between SNS and Amazon CloudWatch provides visibility into the number of messages delivered, as well as the number of messages filtered out.

CloudWatch metrics are captured automatically for you. To get started with SNS message filtering, see Filtering Messages with Amazon SNS.

Message Filtering Metrics

The following six CloudWatch metrics are relevant to understanding your SNS message filtering activity:

  • NumberOfMessagesPublished – Inbound traffic to SNS. This metric tracks all the messages that have been published to the topic.
  • NumberOfNotificationsDelivered – Outbound traffic from SNS. This metric tracks all the messages that have been successfully delivered to endpoints subscribed to the topic. A delivery takes place either when the incoming message attributes match a subscription filter policy, or when the subscription has no filter policy at all, which results in a catch-all behavior.
  • NumberOfNotificationsFilteredOut – This metric tracks all the messages that were filtered out because they carried attributes that didn’t match the subscription filter policy.
  • NumberOfNotificationsFilteredOut-NoMessageAttributes – This metric tracks all the messages that were filtered out because they didn’t carry any attributes at all and, consequently, didn’t match the subscription filter policy.
  • NumberOfNotificationsFilteredOut-InvalidAttributes – This metric keeps track of messages that were filtered out because they carried invalid or malformed attributes and, thus, didn’t match the subscription filter policy.
  • NumberOfNotificationsFailed – This last metric tracks all the messages that failed to be delivered to subscribing endpoints, regardless of whether a filter policy had been set for the endpoint. This metric is emitted after the message delivery retry policy is exhausted, and SNS stops attempting to deliver the message. At that moment, the subscribing endpoint is likely no longer reachable. For example, the subscribing SQS queue or Lambda function has been deleted by its owner. You may want to closely monitor this metric to address message delivery issues quickly.

Message filtering graphs

Through the AWS Management Console, you can compose graphs to display your SNS message filtering activity. The graph shows the number of messages published, delivered, and filtered out within the timeframe you specify (1h, 3h, 12h, 1d, 3d, 1w, or custom).

SNS message filtering for CloudWatch Metrics

To compose an SNS message filtering graph with CloudWatch:

  1. Open the CloudWatch console.
  2. Choose Metrics, SNS, All Metrics, and Topic Metrics.
  3. Select all metrics to add to the graph, such as:
    • NumberOfMessagesPublished
    • NumberOfNotificationsDelivered
    • NumberOfNotificationsFilteredOut
  4. Choose Graphed metrics.
  5. In the Statistic column, switch from Average to Sum.
  6. Title your graph with a descriptive name, such as “SNS Message Filtering”

After you have your graph set up, you may want to copy the graph link for bookmarking, emailing, or sharing with co-workers. You may also want to add your graph to a CloudWatch dashboard for easy access in the future. Both actions are available to you on the Actions menu, which is found above the graph.

Summary

SNS message filtering defines how SNS topics behave in terms of message delivery. By using CloudWatch metrics, you gain visibility into the number of messages published, delivered, and filtered out. This enables you to validate the operation of filter policies and more easily troubleshoot during development phases.

SNS message filtering can be implemented easily with existing AWS SDKs by applying message and subscription attributes across all SNS supported protocols (Amazon SQS, AWS Lambda, HTTP, SMS, email, and mobile push). CloudWatch metrics for SNS message filtering is available now, in all AWS Regions.

For information about pricing, see the CloudWatch pricing page.

For more information, see:

Measuring the throughput for Amazon MQ using the JMS Benchmark

Post Syndicated from Rachel Richardson original https://aws.amazon.com/blogs/compute/measuring-the-throughput-for-amazon-mq-using-the-jms-benchmark/

This post is courtesy of Alan Protasio, Software Development Engineer, Amazon Web Services

Just like compute and storage, messaging is a fundamental building block of enterprise applications. Message brokers (aka “message-oriented middleware”) enable different software systems, often written in different languages, on different platforms, running in different locations, to communicate and exchange information. Mission-critical applications, such as CRM and ERP, rely on message brokers to work.

A common performance consideration for customers deploying a message broker in a production environment is the throughput of the system, measured as messages per second. This is important to know so that application environments (hosts, threads, memory, etc.) can be configured correctly.

In this post, we demonstrate how to measure the throughput for Amazon MQ, a new managed message broker service for ActiveMQ, using JMS Benchmark. It should take between 15–20 minutes to set up the environment and an hour to run the benchmark. We also provide some tips on how to configure Amazon MQ for optimal throughput.

Benchmarking throughput for Amazon MQ

ActiveMQ can be used for a number of use cases. These use cases can range from simple fire and forget tasks (that is, asynchronous processing), low-latency request-reply patterns, to buffering requests before they are persisted to a database.

The throughput of Amazon MQ is largely dependent on the use case. For example, if you have non-critical workloads such as gathering click events for a non-business-critical portal, you can use ActiveMQ in a non-persistent mode and get extremely high throughput with Amazon MQ.

On the flip side, if you have a critical workload where durability is extremely important (meaning that you can’t lose a message), then you are bound by the I/O capacity of your underlying persistence store. We recommend using mq.m4.large for the best results. The mq.t2.micro instance type is intended for product evaluation. Performance is limited, due to the lower memory and burstable CPU performance.

Tip: To improve your throughput with Amazon MQ, make sure that you have consumers processing messaging as fast as (or faster than) your producers are pushing messages.

Because it’s impossible to talk about how the broker (ActiveMQ) behaves for each and every use case, we walk through how to set up your own benchmark for Amazon MQ using our favorite open-source benchmarking tool: JMS Benchmark. We are fans of the JMS Benchmark suite because it’s easy to set up and deploy, and comes with a built-in visualizer of the results.

Non-Persistent Scenarios – Queue latency as you scale producer throughput

JMS Benchmark nonpersistent scenarios

Getting started

At the time of publication, you can create an mq.m4.large single-instance broker for testing for $0.30 per hour (US pricing).

This walkthrough covers the following tasks:

  1.  Create and configure the broker.
  2. Create an EC2 instance to run your benchmark
  3. Configure the security groups
  4.  Run the benchmark.

Step 1 – Create and configure the broker
Create and configure the broker using Tutorial: Creating and Configuring an Amazon MQ Broker.

Step 2 – Create an EC2 instance to run your benchmark
Launch the EC2 instance using Step 1: Launch an Instance. We recommend choosing the m5.large instance type.

Step 3 – Configure the security groups
Make sure that all the security groups are correctly configured to let the traffic flow between the EC2 instance and your broker.

  1. Sign in to the Amazon MQ console.
  2. From the broker list, choose the name of your broker (for example, MyBroker)
  3. In the Details section, under Security and network, choose the name of your security group or choose the expand icon ( ).
  4. From the security group list, choose your security group.
  5. At the bottom of the page, choose Inbound, Edit.
  6. In the Edit inbound rules dialog box, add a role to allow traffic between your instance and the broker:
    • Choose Add Rule.
    • For Type, choose Custom TCP.
    • For Port Range, type the ActiveMQ SSL port (61617).
    • For Source, leave Custom selected and then type the security group of your EC2 instance.
    • Choose Save.

Your broker can now accept the connection from your EC2 instance.

Step 4 – Run the benchmark
Connect to your EC2 instance using SSH and run the following commands:

$ cd ~
$ curl -L https://github.com/alanprot/jms-benchmark/archive/master.zip -o master.zip
$ unzip master.zip
$ cd jms-benchmark-master
$ chmod a+x bin/*
$ env \
  SERVER_SETUP=false \
  SERVER_ADDRESS={activemq-endpoint} \
  ACTIVEMQ_TRANSPORT=ssl\
  ACTIVEMQ_PORT=61617 \
  ACTIVEMQ_USERNAME={activemq-user} \
  ACTIVEMQ_PASSWORD={activemq-password} \
  ./bin/benchmark-activemq

After the benchmark finishes, you can find the results in the ~/reports directory. As you may notice, the performance of ActiveMQ varies based on the number of consumers, producers, destinations, and message size.

Amazon MQ architecture

The last bit that’s important to know so that you can better understand the results of the benchmark is how Amazon MQ is architected.

Amazon MQ is architected to be highly available (HA) and durable. For HA, we recommend using the multi-AZ option. After a message is sent to Amazon MQ in persistent mode, the message is written to the highly durable message store that replicates the data across multiple nodes in multiple Availability Zones. Because of this replication, for some use cases you may see a reduction in throughput as you migrate to Amazon MQ. Customers have told us they appreciate the benefits of message replication as it helps protect durability even in the face of the loss of an Availability Zone.

Conclusion

We hope this gives you an idea of how Amazon MQ performs. We encourage you to run tests to simulate your own use cases.

To learn more, see the Amazon MQ website. You can try Amazon MQ for free with the AWS Free Tier, which includes up to 750 hours of a single-instance mq.t2.micro broker and up to 1 GB of storage per month for one year.

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/755796/rss

Security updates have been issued by Debian (batik, cups, gitlab, ming, and xdg-utils), Fedora (dpdk, firefox, glibc, nodejs-deep-extend, strongswan, thunderbird, thunderbird-enigmail, wavpack, xdg-utils, and xen), Gentoo (ntp, rkhunter, and zsh), openSUSE (Chromium, GraphicsMagick, jasper, opencv, pdns, and wireshark), SUSE (jasper, java-1_7_1-ibm, krb5, libmodplug, and openstack-nova), and Ubuntu (thunderbird).

Шремс подава оплаквания срещу Google, Facebook, Instagram и WhatsApp

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/27/gdpr-schrems/

Макс Шремс подава оплаквания срещу Google, Facebook, Instagram и WhatsApp. Причината е, че според него е незаконен изборът, пред който са изправени потребителите им – да приемат условията на компаниите или да загубят достъп до услугите им.

Подходът “съгласи се или напусни”, казва Шремс пред Reuters Television, нарушава правото на хората съгласно Общия регламент за защита на данните (GDPR) да избират свободно дали да позволят на компаниите да използват данните им. Трябва да има  избор,  смята Шремс.

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

Independent.ie 

The Guardian

Protecting your API using Amazon API Gateway and AWS WAF — Part I

Post Syndicated from Chris Munns original https://aws.amazon.com/blogs/compute/protecting-your-api-using-amazon-api-gateway-and-aws-waf-part-i/

This post courtesy of Thiago Morais, AWS Solutions Architect

When you build web applications or expose any data externally, you probably look for a platform where you can build highly scalable, secure, and robust REST APIs. As APIs are publicly exposed, there are a number of best practices for providing a secure mechanism to consumers using your API.

Amazon API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management.

In this post, I show you how to take advantage of the regional API endpoint feature in API Gateway, so that you can create your own Amazon CloudFront distribution and secure your API using AWS WAF.

AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources.

As you make your APIs publicly available, you are exposed to attackers trying to exploit your services in several ways. The AWS security team published a whitepaper solution using AWS WAF, How to Mitigate OWASP’s Top 10 Web Application Vulnerabilities.

Regional API endpoints

Edge-optimized APIs are endpoints that are accessed through a CloudFront distribution created and managed by API Gateway. Before the launch of regional API endpoints, this was the default option when creating APIs using API Gateway. It primarily helped to reduce latency for API consumers that were located in different geographical locations than your API.

When API requests predominantly originate from an Amazon EC2 instance or other services within the same AWS Region as the API is deployed, a regional API endpoint typically lowers the latency of connections. It is recommended for such scenarios.

For better control around caching strategies, customers can use their own CloudFront distribution for regional APIs. They also have the ability to use AWS WAF protection, as I describe in this post.

Edge-optimized API endpoint

The following diagram is an illustrated example of the edge-optimized API endpoint where your API clients access your API through a CloudFront distribution created and managed by API Gateway.

Regional API endpoint

For the regional API endpoint, your customers access your API from the same Region in which your REST API is deployed. This helps you to reduce request latency and particularly allows you to add your own content delivery network, as needed.

Walkthrough

In this section, you implement the following steps:

  • Create a regional API using the PetStore sample API.
  • Create a CloudFront distribution for the API.
  • Test the CloudFront distribution.
  • Set up AWS WAF and create a web ACL.
  • Attach the web ACL to the CloudFront distribution.
  • Test AWS WAF protection.

Create the regional API

For this walkthrough, use an existing PetStore API. All new APIs launch by default as the regional endpoint type. To change the endpoint type for your existing API, choose the cog icon on the top right corner:

After you have created the PetStore API on your account, deploy a stage called “prod” for the PetStore API.

On the API Gateway console, select the PetStore API and choose Actions, Deploy API.

For Stage name, type prod and add a stage description.

Choose Deploy and the new API stage is created.

Use the following AWS CLI command to update your API from edge-optimized to regional:

aws apigateway update-rest-api \
--rest-api-id {rest-api-id} \
--patch-operations op=replace,path=/endpointConfiguration/types/EDGE,value=REGIONAL

A successful response looks like the following:

{
    "description": "Your first API with Amazon API Gateway. This is a sample API that integrates via HTTP with your demo Pet Store endpoints", 
    "createdDate": 1511525626, 
    "endpointConfiguration": {
        "types": [
            "REGIONAL"
        ]
    }, 
    "id": "{api-id}", 
    "name": "PetStore"
}

After you change your API endpoint to regional, you can now assign your own CloudFront distribution to this API.

Create a CloudFront distribution

To make things easier, I have provided an AWS CloudFormation template to deploy a CloudFront distribution pointing to the API that you just created. Click the button to deploy the template in the us-east-1 Region.

For Stack name, enter RegionalAPI. For APIGWEndpoint, enter your API FQDN in the following format:

{api-id}.execute-api.us-east-1.amazonaws.com

After you fill out the parameters, choose Next to continue the stack deployment. It takes a couple of minutes to finish the deployment. After it finishes, the Output tab lists the following items:

  • A CloudFront domain URL
  • An S3 bucket for CloudFront access logs
Output from CloudFormation

Output from CloudFormation

Test the CloudFront distribution

To see if the CloudFront distribution was configured correctly, use a web browser and enter the URL from your distribution, with the following parameters:

https://{your-distribution-url}.cloudfront.net/{api-stage}/pets

You should get the following output:

[
  {
    "id": 1,
    "type": "dog",
    "price": 249.99
  },
  {
    "id": 2,
    "type": "cat",
    "price": 124.99
  },
  {
    "id": 3,
    "type": "fish",
    "price": 0.99
  }
]

Set up AWS WAF and create a web ACL

With the new CloudFront distribution in place, you can now start setting up AWS WAF to protect your API.

For this demo, you deploy the AWS WAF Security Automations solution, which provides fine-grained control over the requests attempting to access your API.

For more information about deployment, see Automated Deployment. If you prefer, you can launch the solution directly into your account using the following button.

For CloudFront Access Log Bucket Name, add the name of the bucket created during the deployment of the CloudFormation stack for your CloudFront distribution.

The solution allows you to adjust thresholds and also choose which automations to enable to protect your API. After you finish configuring these settings, choose Next.

To start the deployment process in your account, follow the creation wizard and choose Create. It takes a few minutes do finish the deployment. You can follow the creation process through the CloudFormation console.

After the deployment finishes, you can see the new web ACL deployed on the AWS WAF console, AWSWAFSecurityAutomations.

Attach the AWS WAF web ACL to the CloudFront distribution

With the solution deployed, you can now attach the AWS WAF web ACL to the CloudFront distribution that you created earlier.

To assign the newly created AWS WAF web ACL, go back to your CloudFront distribution. After you open your distribution for editing, choose General, Edit.

Select the new AWS WAF web ACL that you created earlier, AWSWAFSecurityAutomations.

Save the changes to your CloudFront distribution and wait for the deployment to finish.

Test AWS WAF protection

To validate the AWS WAF Web ACL setup, use Artillery to load test your API and see AWS WAF in action.

To install Artillery on your machine, run the following command:

$ npm install -g artillery

After the installation completes, you can check if Artillery installed successfully by running the following command:

$ artillery -V
$ 1.6.0-12

As the time of publication, Artillery is on version 1.6.0-12.

One of the WAF web ACL rules that you have set up is a rate-based rule. By default, it is set up to block any requesters that exceed 2000 requests under 5 minutes. Try this out.

First, use cURL to query your distribution and see the API output:

$ curl -s https://{distribution-name}.cloudfront.net/prod/pets
[
  {
    "id": 1,
    "type": "dog",
    "price": 249.99
  },
  {
    "id": 2,
    "type": "cat",
    "price": 124.99
  },
  {
    "id": 3,
    "type": "fish",
    "price": 0.99
  }
]

Based on the test above, the result looks good. But what if you max out the 2000 requests in under 5 minutes?

Run the following Artillery command:

artillery quick -n 2000 --count 10  https://{distribution-name}.cloudfront.net/prod/pets

What you are doing is firing 2000 requests to your API from 10 concurrent users. For brevity, I am not posting the Artillery output here.

After Artillery finishes its execution, try to run the cURL request again and see what happens:

 

$ curl -s https://{distribution-name}.cloudfront.net/prod/pets

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: [removed]
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

As you can see from the output above, the request was blocked by AWS WAF. Your IP address is removed from the blocked list after it falls below the request limit rate.

Conclusion

In this first part, you saw how to use the new API Gateway regional API endpoint together with Amazon CloudFront and AWS WAF to secure your API from a series of attacks.

In the second part, I will demonstrate some other techniques to protect your API using API keys and Amazon CloudFront custom headers.

Use Slack ChatOps to Deploy Your Code – How to Integrate Your Pipeline in AWS CodePipeline with Your Slack Channel

Post Syndicated from Rumi Olsen original https://aws.amazon.com/blogs/devops/use-slack-chatops-to-deploy-your-code-how-to-integrate-your-pipeline-in-aws-codepipeline-with-your-slack-channel/

Slack is widely used by DevOps and development teams to communicate status. Typically, when a build has been tested and is ready to be promoted to a staging environment, a QA engineer or DevOps engineer kicks off the deployment. Using Slack in a ChatOps collaboration model, the promotion can be done in a single click from a Slack channel. And because the promotion happens through a Slack channel, the whole development team knows what’s happening without checking email.

In this blog post, I will show you how to integrate AWS services with a Slack application. I use an interactive message button and incoming webhook to promote a stage with a single click.

To follow along with the steps in this post, you’ll need a pipeline in AWS CodePipeline. If you don’t have a pipeline, the fastest way to create one for this use case is to use AWS CodeStar. Go to the AWS CodeStar console and select the Static Website template (shown in the screenshot). AWS CodeStar will create a pipeline with an AWS CodeCommit repository and an AWS CodeDeploy deployment for you. After the pipeline is created, you will need to add a manual approval stage.

You’ll also need to build a Slack app with webhooks and interactive components, write two Lambda functions, and create an API Gateway API and a SNS topic.

As you’ll see in the following diagram, when I make a change and merge a new feature into the master branch in AWS CodeCommit, the check-in kicks off my CI/CD pipeline in AWS CodePipeline. When CodePipeline reaches the approval stage, it sends a notification to Amazon SNS, which triggers an AWS Lambda function (ApprovalRequester).

The Slack channel receives a prompt that looks like the following screenshot. When I click Yes to approve the build promotion, the approval result is sent to CodePipeline through API Gateway and Lambda (ApprovalHandler). The pipeline continues on to deploy the build to the next environment.

Create a Slack app

For App Name, type a name for your app. For Development Slack Workspace, choose the name of your workspace. You’ll see in the following screenshot that my workspace is AWS ChatOps.

After the Slack application has been created, you will see the Basic Information page, where you can create incoming webhooks and enable interactive components.

To add incoming webhooks:

  1. Under Add features and functionality, choose Incoming Webhooks. Turn the feature on by selecting Off, as shown in the following screenshot.
  2. Now that the feature is turned on, choose Add New Webhook to Workspace. In the process of creating the webhook, Slack lets you choose the channel where messages will be posted.
  3. After the webhook has been created, you’ll see its URL. You will use this URL when you create the Lambda function.

If you followed the steps in the post, the pipeline should look like the following.

Write the Lambda function for approval requests

This Lambda function is invoked by the SNS notification. It sends a request that consists of an interactive message button to the incoming webhook you created earlier.  The following sample code sends the request to the incoming webhook. WEBHOOK_URL and SLACK_CHANNEL are the environment variables that hold values of the webhook URL that you created and the Slack channel where you want the interactive message button to appear.

# This function is invoked via SNS when the CodePipeline manual approval action starts.
# It will take the details from this approval notification and sent an interactive message to Slack that allows users to approve or cancel the deployment.

import os
import json
import logging
import urllib.parse

from base64 import b64decode
from urllib.request import Request, urlopen
from urllib.error import URLError, HTTPError

# This is passed as a plain-text environment variable for ease of demonstration.
# Consider encrypting the value with KMS or use an encrypted parameter in Parameter Store for production deployments.
SLACK_WEBHOOK_URL = os.environ['SLACK_WEBHOOK_URL']
SLACK_CHANNEL = os.environ['SLACK_CHANNEL']

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    print("Received event: " + json.dumps(event, indent=2))
    message = event["Records"][0]["Sns"]["Message"]
    
    data = json.loads(message) 
    token = data["approval"]["token"]
    codepipeline_name = data["approval"]["pipelineName"]
    
    slack_message = {
        "channel": SLACK_CHANNEL,
        "text": "Would you like to promote the build to production?",
        "attachments": [
            {
                "text": "Yes to deploy your build to production",
                "fallback": "You are unable to promote a build",
                "callback_id": "wopr_game",
                "color": "#3AA3E3",
                "attachment_type": "default",
                "actions": [
                    {
                        "name": "deployment",
                        "text": "Yes",
                        "style": "danger",
                        "type": "button",
                        "value": json.dumps({"approve": True, "codePipelineToken": token, "codePipelineName": codepipeline_name}),
                        "confirm": {
                            "title": "Are you sure?",
                            "text": "This will deploy the build to production",
                            "ok_text": "Yes",
                            "dismiss_text": "No"
                        }
                    },
                    {
                        "name": "deployment",
                        "text": "No",
                        "type": "button",
                        "value": json.dumps({"approve": False, "codePipelineToken": token, "codePipelineName": codepipeline_name})
                    }  
                ]
            }
        ]
    }

    req = Request(SLACK_WEBHOOK_URL, json.dumps(slack_message).encode('utf-8'))

    response = urlopen(req)
    response.read()
    
    return None

 

Create a SNS topic

Create a topic and then create a subscription that invokes the ApprovalRequester Lambda function. You can configure the manual approval action in the pipeline to send a message to this SNS topic when an approval action is required. When the pipeline reaches the approval stage, it sends a notification to this SNS topic. SNS publishes a notification to all of the subscribed endpoints. In this case, the Lambda function is the endpoint. Therefore, it invokes and executes the Lambda function. For information about how to create a SNS topic, see Create a Topic in the Amazon SNS Developer Guide.

Write the Lambda function for handling the interactive message button

This Lambda function is invoked by API Gateway. It receives the result of the interactive message button whether or not the build promotion was approved. If approved, an API call is made to CodePipeline to promote the build to the next environment. If not approved, the pipeline stops and does not move to the next stage.

The Lambda function code might look like the following. SLACK_VERIFICATION_TOKEN is the environment variable that contains your Slack verification token. You can find your verification token under Basic Information on Slack manage app page. When you scroll down, you will see App Credential. Verification token is found under the section.

# This function is triggered via API Gateway when a user acts on the Slack interactive message sent by approval_requester.py.

from urllib.parse import parse_qs
import json
import os
import boto3

SLACK_VERIFICATION_TOKEN = os.environ['SLACK_VERIFICATION_TOKEN']

#Triggered by API Gateway
#It kicks off a particular CodePipeline project
def lambda_handler(event, context):
	#print("Received event: " + json.dumps(event, indent=2))
	body = parse_qs(event['body'])
	payload = json.loads(body['payload'][0])

	# Validate Slack token
	if SLACK_VERIFICATION_TOKEN == payload['token']:
		send_slack_message(json.loads(payload['actions'][0]['value']))
		
		# This will replace the interactive message with a simple text response.
		# You can implement a more complex message update if you would like.
		return  {
			"isBase64Encoded": "false",
			"statusCode": 200,
			"body": "{\"text\": \"The approval has been processed\"}"
		}
	else:
		return  {
			"isBase64Encoded": "false",
			"statusCode": 403,
			"body": "{\"error\": \"This request does not include a vailid verification token.\"}"
		}


def send_slack_message(action_details):
	codepipeline_status = "Approved" if action_details["approve"] else "Rejected"
	codepipeline_name = action_details["codePipelineName"]
	token = action_details["codePipelineToken"] 

	client = boto3.client('codepipeline')
	response_approval = client.put_approval_result(
							pipelineName=codepipeline_name,
							stageName='Approval',
							actionName='ApprovalOrDeny',
							result={'summary':'','status':codepipeline_status},
							token=token)
	print(response_approval)

 

Create the API Gateway API

  1. In the Amazon API Gateway console, create a resource called InteractiveMessageHandler.
  2. Create a POST method.
    • For Integration type, choose Lambda Function.
    • Select Use Lambda Proxy integration.
    • From Lambda Region, choose a region.
    • In Lambda Function, type a name for your function.
  3.  Deploy to a stage.

For more information, see Getting Started with Amazon API Gateway in the Amazon API Developer Guide.

Now go back to your Slack application and enable interactive components.

To enable interactive components for the interactive message (Yes) button:

  1. Under Features, choose Interactive Components.
  2. Choose Enable Interactive Components.
  3. Type a request URL in the text box. Use the invoke URL in Amazon API Gateway that will be called when the approval button is clicked.

Now that all the pieces have been created, run the solution by checking in a code change to your CodeCommit repo. That will release the change through CodePipeline. When the CodePipeline comes to the approval stage, it will prompt to your Slack channel to see if you want to promote the build to your staging or production environment. Choose Yes and then see if your change was deployed to the environment.

Conclusion

That is it! You have now created a Slack ChatOps solution using AWS CodeCommit, AWS CodePipeline, AWS Lambda, Amazon API Gateway, and Amazon Simple Notification Service.

Now that you know how to do this Slack and CodePipeline integration, you can use the same method to interact with other AWS services using API Gateway and Lambda. You can also use Slack’s slash command to initiate an action from a Slack channel, rather than responding in the way demonstrated in this post.

timeShift(GrafanaBuzz, 1w) Issue 46

Post Syndicated from Blogs on Grafana Labs Blog original https://grafana.com/blog/2018/05/24/timeshiftgrafanabuzz-1w-issue-46/

Welcome to TimeShift The day has finally arrived; GDPR is officially in effect! These new policies are meant to provide more transparency about the data companies collect on users, and how that data is used. I for one am just excited that the onslaught of "We’ve updated our privacy policy" emails arriving in my pummeled inbox is nearing its end.
Grafana Labs is no exception. We encourage you to check out our privacy policy, and if you have any questions, feel free to contact us at [email protected]