Autentificarea Temeinică a Clienților

Ce înseamnă autentificarea temeinică a clienților, cunoscută în limba engleză sub numele de „Strong Customer Authentication” sau SCA pe scurt?

Autentificarea temeinică a clientului este definită ca o autentificare bazată pe utilizarea a două sau mai multe elemente clasificate drept cunoștințe, posesii și inerențe. Să vedem așadar ce înseamnă fiecare în parte.

Elementul cunoștințe reprezintă ceva ce numai utilizatorul știe cum ar fi de exemplu o parolă ce conține numele câinelui utilizatorului. Elementul posesie reprezintă ceva ce numai utilizatorul posedă cum ar fi de exemplu codul numeric personal sau cardul bancar iar elementul inerență reprezintă ceva ce utilizatorul este, cum ar fi amprenta digitală.

Aceste elemente de autentificare trebuie să fie independente unele de altele, prin faptul că devoalarea uneia să nu compromită fiabilitatea celorlalte. Această metodologie de autentificare este astfel concepută încât să protejeze confidențialitatea datelor clienților. Totodată metodologia trebuie să respecte reglementările internaționale, cum ar fi PCI-DSS (Payment Card Industry Data Security Standard) și desigur PSD2.

PSD2 reprezintă a doua iterație a „Directivei privind serviciile de plată” (Payment Services Directive – PSD), o directivă a Uniunii Europene (UE) introdusă prima dată în 2007 pentru a reglementa serviciile de plată și furnizorii de servicii de plată (payment service providers – PSP). Această directivă europeană, PSD, a permis o mai bună concurență paneuropeană vizavi de participarea furnizorilor de servicii la industria de plăți, în timp ce directiva amenință să rupă monopolul industriei bancare privind facilitarea plăților securizate online. Mulți sunt preocupați astăzi de implicațiile adaptării tehnologiei la SCA în PSD2 însă motivele de îngrijorare nu sunt justificate. Concurența pe piața globală a firmelor de securitate oferă o gamă largă de produse IAM – Identity and Access Management adaptate la nevoile și legislația actuală.

În continuare sunt listate câteva dintre soluțiile existenta pe piață.

Oracle Identity Management
Microsoft Azure Active Directory
Okta Identity Cloud
ForgeRock Identity Platform

Dan Bârsan

Advertisement

Care este rolul unui arhitect de program?

Care este rolul unui arhitect de program?

„Arhitect” de aplicații este numele dat uneori unei persoane importante care lucrează în departamentul de dezvoltare software alteori acest apelativ este acordat celor care înțeleg funcționalitatea unei anumite aplicații. Pentru unii oameni această titulatură este văzută doar ca un pas înainte în cariere profesională iar pentru majoritatea oamenilor cuvântul arhitect descrie o persoană care trasează linii și dreptunghiuri pe o planșă.

Una peste alta vorbind de „arhitect” și arhitectura de aplicații majoritatea dintre noi nu știu în fapt ce exprimă acest termen. În articolul de față voi încerca să clasific rolurilor de arhitect și să le descriu cu mai multe detalii.

Nu există doar un singur tip de arhitect

În teorie există un număr destul de mare de titulaturi care specifică o poziție de arhitect. De exemplu există arhitectul de sistem, de business, de software, de aplicație sau poziția de enterprise arhitect. Probabil din acest motiv, o mulțime de cărți și articole definesc oarecum diferit aceste roluri, definițiile date uneori excluzându-se reciproc. Pentru a simplifica modul de clasificare al pozițiilor de arhitect voi defini rolul respectiv în funcție de nivelul de abstractizare al percepției noțiunii de software.

I. În marile corporații, care dețin sisteme informatice proprii ce sunt necesare sprijinirii proceselor externe, există poziția de Enterprise Arhitect. Persoana, care deține această poziție, are responsabilitatea de a conduce o analiză globală a afacerilor întreprinderii și de a proiecta o soluție de afaceri care să satisfacă nevoilor companiei în ansamblul său. Deși rolul în cauză necesită cunoștințe tehnice, cel mai important aspect al poziției respective este înțelegerea nevoilor de business ale organizației. Adesea arhitectul enterprise poate sugera dezvoltarea unei soluții dedicate sau poate selecta soluția software optimă pentru sprijinul proceselor de securitate, gestiune și producție ale organizației.

II. Coborând pe o scara abstractizării noțiunii de software, întâlnim o poziție de Architect de Sistem. Persoana care deține acest rol este mandatată să proiecteze interacțiunea dintre sisteme și impune restricții privind utilizarea platformelor și al aplicațiilor. În plus, ea stabilește standardele globale prin care sunt interconectate sistemele și cu ajutorul cărora se realizează comunicarea și o bună funcționare a acestora.

III. Pe scara inferioară de abstractizare a poziției de arhitect, putem observa că rolul arhitectului începe să se amestece cu cel al programatorului. Desenele, care apar uneori pe planșele de proiectare, pot fi mai frecvent transferate în componente, biblioteci, straturi sau chiar clase și metode. Aceasta este poziția de Arhitect de Aplicație sau Software Architect. Această persoană operează de obicei într-un domeniu care se ocupă de implementare unei aplicații sau a unui sistem informatic. Sarcina sa principală este de a monitoriza întregul sistem, de a înțelege toate interacțiunile dintre componente la un anumit nivel de abstractizare, precum și de a defini limitările și cerințele codului sursă.

Așa cum am menționat anterior, această clasificare este doar o simplificare a descrierii rolului de arhitect. Scopul meu este să evidențiez faptul că a spune „arhitect” în ceea ce privește dezvoltarea de software nu este suficient. După cum am arătat pot exista mai mulți arhitecți cu responsabilități diferite într-o singură organizație. De asemenea, același tip de arhitect poate face lucruri diferite în organizații diferite. Probabil că aceasta este sursa celei mai mari ambiguități atunci când vine vorba de cuvântul „arhitect”.

va continua,

EA și tehnologia informațională

Enterprise Architecture, pe scurt EA, este o disciplină bine definită pentru realizarea ordonată a analizei, proiectării, planificării și dezvoltării unei întreprinderi. Acest lucru este obținut printr-o abordare atotcuprinzătoare, în vederea implementării cu succes a strategiei organizației. De asemenea EA prevede adaptarea la schimbările survenite în mediul de afaceri, procesarea rapidă a informațiilor și actualizarea proceselor și tehnologiilor necesare executării strategiilor organizației.

Aceste practici se interpun diverselor aspecte ale activitățiilor unei întreprinderi pentru identificarea, motivarea și realizarea unor ajustări sau după caz schimbări în cadrul acesteia. Arhitectul întreprinderii, este responsabili pentru realizarea analizei structurii și proceselor de afaceri. El este cel desemnat să tragă concluzii din informațiile colectate pentru a evalua corespunzător obiectivele arhitecturii întreprinderii precum: eficiența, agilitatea și continuitatea unor activității complexe.

Mandatory Elements Required to Create a TCO Assessment

Tags

TCO, Total cost of ownership

Total Cost of Ownership

Regardless of the objective of the analysis, several mandatory elements must be included for the analysis to qualify as a Gartner TCO:
• Identify the domain or activity for which an annual TCO is required (for example, distributed computing, telecommunications or data center), or to make a specific decision, such as, “Will server consolidation really save us money?”
• Develop a chart of accounts, which is a list of cost elements that refers to TCO as
defined above. For IT costs, this must include or evaluate the following:
• Direct cost elements relating to assets or activities that are relevant to the analysis;
for example:
• Client, server, storage and all peripheral hardware costs
• Software and related support costs
• Maintenance and development costs
• Networking and communications costs
• IT operations and support costs
• Associated indirect cost elements — for example, labor costs associated with the end user’s use of an asset or activity, and any subsequent downtime involved.
• Ensure that the chart of accounts contains cost elements that satisfy the TCO definition’s criteria for “holistic view” and “enterprise boundaries” — that is, taking a wider view of costs than normally occurs. Rather than simply being concerned about identifying and listing the costs within a specific function or department, the chart of accounts must also contain cost elements or cost categories that could be affected by activities or changes in the domain. For example, the chart of accounts for a help desk TCO may include cost elements outside of IT operations or IT support. Limiting the chart of accounts to cost elements only contained within IT operations is misleading, because help desk users incur a cost in the form of time spent and, thus, opportunity lost. Indirect costs may be associated with other departmental budgets, but they are still part of a properly constructed TCO. It’s easy to turn a blind eye to such costs — for example, assuming that they’re too small to be relevant, while ignoring the multiplication factor caused by the many individuals who are involved.
• Review the chart of accounts to ensure that all of its elements represent an annualized view of the TCO in question. The chart of accounts should contain details on critical affecting factors (such as depreciation periods) because these will significantly affect any annualized view.
• Review all chart-of-accounts elements to ensure that critical cost elements have been included and don’t overlap, thus avoiding double counting.
• Collect and validate information regarding the costs and other data required to populate the chart of accounts. Use the enterprise’s financial management system, asset management system and HR records to detail unit costs, and use survey questionnaires to establish people’s use of time.
• Amortize all cost elements in the chart of accounts during a specified time period (such as annual, quarterly and so on). For example, a server with a three-year depreciation period would be included in the chart of accounts as one-third of the total server cost.

Service Level Agreement – a HIAL implementation proposal for eHealth Ontario

Tags

eHealth Blueprint, eHealth Ontario, enterprise architecture, Service Level Agreement, SLA

eHealth Ontario

The SLA is a formal document outlining a service commitment provided by an IT service provider to one or more customers. The Service Level Management mission statement is to “plan, coordinate, negotiate, report and manage the quality of IT services at acceptable cost”.

The scope of the SLA project is to implement an enterprise framework that adapts to changing business priorities and service levels, define clear goals to shape the service offered by the provider, and avoid the back and forth associated with service level disagreements.

SLA benefits include open communication and the ability to manage the customers’ expectations. IT organizations also benefit from a clearer picture of what the users need, the ability to balance and adjust their resources to meet those expectations, as well as explicitly detail the costs associated with any given level of service.

For more details check the following attached PDF document: