SAP Community - SAP BTP, Kyma runtime

B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP 🚀

2024-05-07T09:54:43.546000+02:00

B2B Business Processes - there are many Business Processes which cross Company and Organisation boundaries.

What has that got to do with Enterprise Blockchain and Cyber Security ? Let's find out.

This is a great Enterprise Blockchain story, it's one of my favourites, like the BCP one, it's so easy to implement and so effective and protects Data and Systems and Business Partners across so many dimensions, read on to find out why.

So buckle up and enjoy the ride...

B2B Business Processes, also known as, Multi-Party Collaboration, the following common Business Processes and others can all include elements of 3rd Party Organisation integration:

Order-To-Cash
Procure-To-Pay
Plan-To-Produce/Plan-To-Inventory
Record-To-Report
Source-To-Pay
Idea-To-Offering
Count-To-Reconcile
Forecast-To-Monitor
Inspect-To-Comply
Cradle-To-Grave/Acquire-To-Retire

Where ever you have a Business Process which includes sending your Data to a 3rd Party Organisation, to another Company, your Data is being put at risk. When ever you send or replicate or integrate your Company's Data to another Company your Data is at risk, and this means your Business Process is at risk and therefore your Business is at risk.

This blog is going to be talking about and showing is the weakness of the current approach of working with Data across multiple Organisations which collaborate together on a Business Process.

An easy example is 3PL 3rd Party Logistics.

Your Company needs something delivered and your S/4HANA system sends an instruction to the 3rd Party Logistics company to make a collection and a delivery.

This all looks very normal and very common, but what is actually happening when your Company sends an instruction from the S/4HANA system to the Delivery Planning System at your Partner Company the 3PL 3rd Party Logistics Company ?

Data, it's all about Data, your S/4HANA system is sending Data to your Business Partner the 3rd Party Logistics Company instructing them on where to collect from or deliver to.

And this is the problem, as soon as your Data leaves your network, it's no longer your Data, and you lose control of the Data.

This is a classical Integration scenario, the S/4HANA is Integrated to the 3rd Party Logistics Company's System and you send them your Data. What happens to that Data at your Business Partner is beyond your control, you can only trust that they will care for your Data the same way as they would care for their own Data.

This is how you are doing it today, with IDOCS and API's, this is legacy Data Integration through Replication:

Cyber Security Risk SAP Customers have to share Master Data with Partners Legacy Integration through Data Replication atkrypto.io

This creates several problems including:

Trust between Partners: The more Partners in a Business Transaction or Business Process, the less trust there is between Partners. This is a very simple graph, as the number of Partners in a Business Transaction or Business Process goes up, so the trust between the Partners goes down. What is trust in a Business Transaction or Business Process, doing what you said you would, data, instruction, confirmation. I will deliver the parcel to the address you gave me, but what if somebody in my Team changes the delivery address for their own benefit ?

Protect the Originality & Integrity of the Data - When your S/4HANA sends the Data to your Business Partner's System we need to make sure that the Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

Replicating & Integrating the Data from your S/4HANA to your Business Partner's System and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the S/4HANA to the Business Partner's System and we need to be sure, to have surety that the Data which arrives at the Business Partner's System is the same Data as was sent from your S/4HANA. If this Data can be changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

and it doesn't end there, it's often the case that a 3rd Party Organisation will be getting Data directly from your S/4HANA (as the Source) or posting Data to your S/4HANA (as the Target), in both cases it could be an API which through your Integration Technologies is ultimately exposed to the Internet and where the system calling the API needs to have a User on your S/4HANA.

And 3rd Party Logistics is only the tip of the iceberg when it comes to Multi-Party Collaboration and Business Transactions and Business Processes. You know how integrated your Systems are with your Business Partners how the data is flowing in and out of your network to and from your Partner's networks.

And so, here we are,

The biggest threat to B2B Business Processes is Cyber Security and Cyber Attacks

The biggest threat to Multi-Party Collaboration is Cyber Security and Cyber Attacks

And that's where the Enterprise Blockchain comes in, and this blog is going to explain why.

This blog will be less about deep dives into Use Cases and more about how Enterprise Blockchain is:

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

Subsequent blogs will deep dive individual use case by use case, this one will focus on the principle of Enterprise Blockchain already today being the next generation Secure Store and Secure Communication Channel for Data and how and why.

Ok let's go 🚀

Welcome to the ninth blog in this series on Enterprise Blockchain and SAP. If you have been following the previous blogs then you'll be familiar with the blog template. We'll begin by talking about and framing the problem, in this case Data Cyber Security for B2B Business Processes and then go in to identifying the enabling technology which will have the best capabilities and be the most appropriate to solving the problem all the way through to the reference solution architecture to be able to implement the solution.

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of B2B Business Processes and SAP, and Enterprise Blockchain

Section 2.0: The Why is it, of B2B Business Processes and SAP, and Enterprise Blockchain

Section 3.0: The How is it, of B2B Business Processes and SAP, and Enterprise Blockchain

In case you missed them, the previous blogs in this series are here:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain🚀

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT🚀

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

tl:dr

Enterprise Integrations and Integration Architecture centered around sending and replicating Data to Business Partners results in you losing control of your Data, and losing surety that the Business Partner is looking at the same Data as you are.

The Digital Transformation of Enterprise Integrations is to have a shared common single source of truth for data with your Business Partners.

Enterprise Blockchain is the answer, Enterprise Blockchain enables both Business Partners, you and your Business Partner to share the same Distributed Ledger and consequently have a common shared single source of truth for data across multiple Companies.

That's one thing, the next thing is that thanks to the special characteristics of the Enterprise Blockchain Distributed Ledger, namely, Immutable, Hash Mechanism, Consensus, Distributed, when you or your Business Partner write data to the Enterprise Blockchain, you know, that nobody can modify the Data for their own gains, your know that natively, out of the box you have the highest level of Data Cyber Security and Resilience of any commercial database product available.

In the 3PL scenario, this is what your SAP Technical Architecture would look like:

Enterprise Blockchain as a Shared Common Single Source of Truth for Master and Transactional Data across Organisations with SAP BTP and atkrypto.io

[the finer technical details of the Technical Solution Architecture will be elaborated in the rest of the blog]

The Future of Enterprise Collaboration and Cross Organisation Data Integration and B2B Business Processes (and this is possible today with the SAP BTP and SAP Partner Edge Open EcoSystem Partner Enterprise Blockchain Products).

And as will be explained later in the blog, it's not only about the Enterprise Blockchain being a common shared source of truth across organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

This is like pick your own strawberries, instead of sending your Partners the strawberries, you tell your Partner the strawberries are ready and which field they are in and you let your Partners pick the strawberries themselves from the Enterprise Blockchain.

S/4HANA Data Events write the Data to the Enterprise Blockchain and S/4HANA Notification Events notify the Partner that something has happened, then, instead of calling an API on your SAP S/4HANA, the Partner then calls the API of the Enterprise Blockchain and Reads the Data from there.

The Enterprise Blockchain Database software is running on your SAP BTP Kyma Runtime and in your Partner's Servers, therefore, creating natively, out of the box, the most secure and resilient common shared single source of truth. Your have a Distributed Ledger running from your SAP BTP to the Partner's Servers.

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

Therefore, S/4HANA Data Event Writes to the Enterprise Blockchain as the Common Shared Single Source of Truth across the Organisations, and the S/4HANA Notification Event notifies the Partner that something has happened and that they should call the Enterprise Blockchain API to get the Data of what has happened.

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. a Shared Common Single Source of Truth for Master and Transactional Data across Organisations

Enterprise Blockchain is the Cyber Security for Enterprise B2B Business Processes and Multi Party Collaboration.

and now.... the long answer...

Section 1.0: The What is it of B2B Business Processes and SAP, and Enterprise Blockchain

What are B2B Business Processes, what is Multi-Party Collaboration, what are 3rd Party Integrations, what is it all and why do we need it ?

B2B Business Processes, Multi-Party Collaboration, in the context of this subject, these are any Business Process in your Company which includes your Master and Transactional S/4HANA Data being used by another Company, and results in the other Company needing access to your Data.

There are many examples, in today's world of outsourcing that which is not considered part of the core Business, Multi-Party Collaboration is very common across most lines of the Business. Another easy and common one is outsources Payroll.

As described in this blog, by @mert_turan , your Company is using a 3rd Party Payroll provider to take care of your Payroll, the process and the integration can look like this:

Payroll Process by Mert Turan

This is a classic example of a B2B Business Process, where your Company is sending highly sensitive and highly confidential Data, transferring that Data to a 3rd Party Company, in this case a 3rd Party Payroll Provider. Look at all of the Data transfers which are going on in that Payroll Business Process.

Just look at the sensitivity and confidentiality of the Data which is being transferred to the 3rd Party Company, Personal and Business Sensitive Master and Transactional Data.

What could possibly go wrong ?

What could possibly go wrong with any of these Multi-Party Collaborative Business Processes, Payroll, Supplier Network Collaboration, 3rd Party Logistics, Contract Manufacturing ?

What is the biggest risk ?

The Data, again, it's all about the Data, and keeping the Data safe, and reducing the chance that somebody can mess with the Data.

What about the Enterprise Blockchain, what is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". If we just pause for a moment and let that sink in, and think about what that means, to Business Processes, to Collaboration, to System Resilience, we start to see what is so special about Blockchain Databases and Distributed Ledger Technology.

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. B2B Business Processes are about Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of B2B Business Processes and SAP, and Enterprise Blockchain

So, why B2B Business Processes in the Enterprise IT, when implemented in conjunction with SAP Applications need Enterprise Blockchain ?

Multi-Party Collaboration is about replicating Data to 3rd Party Company, and the Data, this is your Company's Data and in most cases highly sensitive and highly business and personally confidential.

The problem is the Cyber Security of getting the Data from the your Company's SAP S/4HANA to the 3rd Party Company's Application, and ensuring the originality and integrity of the highly sensitive and confidential Master and Transactional Data which you are replicating to the Partner Company remains intact.

As we talked about earlier, and this is worth repeating because this is the problem of Multi-Party Collaboration:

ITSecurityWire.com, in their article, Best Practices to Secure Data Integration, put it like this:

The LinkedIn Community describe the risks of Data integration like this:

Those are the problems with today's legacy ways of making your S/4HANA Master and Transaction Data available for 3rd Party Companies in your B2B Business Processes.

And what's the solution ?

The solution is the Enterprise Blockchain as the Common Data Back Bone across Companies.

Instead of replicating and sending the Data to your Business Partner, you write the S/4HANA Data to the Enterprise Blockchain.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make Data for B2B Business Process the safest it can be, the most trustable that it can be.

When we look in our Enterprise Technology Standards, and we look for the Technology Standard in our Enterprise Portfolio which is positioned to bring the strongest protection to Data, we find the Enterprise Blockchain.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

In the previous blogs, we have discussed in detail about the special characteristics of Enterprise Blockchain and just why it natively out of the box protects the integrity of data to a level that legacy database products cannot do, in a nutshell....

B2B Business Processes are about Data

B2B Business Processes are about the Data that goes from your S/4HANA outside the boundaries of your Company and your Network and to Partner Company's Applications and Networks and Databases.

This means B2B Business Processes are about Data and the Data depends on a Database or a Datastore

What kind of Database do B2B Business Processes Data need ? What capabilities does the Database for the B2B Business Processes Data need to have ?

1. It must not be possible to modify the Data in the Database ]- the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

4. The Database must be running simutaneously in your DataCenter and your Business Partner's DataCenter

5. S/4HANA must not expose any API's to Business Partner Companies

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those boxes...

Immutable - tick that box

Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

DeCouples S/4HANA from the process, no need to S/4HANA API's to be exposed to 3rd Party Business Partner's Applications

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise B2B Business Processes.

atkrypto.io what is a blockchain

But there's more than that, B2B Business Processes can produce a lot of data, and the volumes of data can be big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

As we have explained in a previous blog, the Enterprise Blockchain Database, the Distributed Ledger, can be looked at simply as a Database Table (which is replicated and synchronised across multiple Servers) and in principle it stores the Data like this:

Blockchain is a very simple form of database atkrypto.io

This is fine, and suited to what we call Structured Data, and as AWS nicely describe, Structured Data is information like words and numbers. This kind of data is perfectly suited to being stored in an Enterprise Blockchain Database and also a legacy Database. Examples of the data would Names, Addresses, Phone Numbers, Product Information etc.

But, Payroll can produce a lot of Data, and in large volumes which would be too big to be stored on the Enterprise Blockchain Database itself.

And that's ok, Enterprise Blockchain Platforms are ready for that, and have been designed to store both Structured Data and Data which is in files which are so big that they cannot be stored in the Enterprise Blockchain Database itself, for example the photographs from a Waste Truck's onboard camera proving that waste was responsibly tipped in the correct location and taken at the same time as recording GPS location coordinates proving the location of the Waste Truck.

So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

Voila.... bring in the Enterprise Blockchain Platform Wallet. The best Enterprise Blockchain Platform products include what is called the Enterprise Blockchain Platform Wallet, or to make it shorter, the Enterprise Blockchain Wallet.

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The way this works is elegant, in any decent Enterprise Blockchain Platform, the Enterprise Blockchain Wallet location is completely configurable, and could be anywhere from SAP HANA Cloud (Data Lake), or for example multiple hyperscaler object stores, such as Amazon S3, OSS (Alicloud Object Storage
Service), SAP HANA Cloud, Data Lake, and Azure Blob Storage.

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the large volumes of Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

What happens is this, when store data in the Enterprise Blockchain Wallet, the Enterprise Blockchain Platform software runs a hash algorithm over the data that we have stored and the data, and the large file gets hashed:

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

This means we now have a unique hash of that data or file, and if anybody or anything makes even the tiniest teeniest change to that data or file, next time we run a hash over that data or file the result will be different that the original hash which is safely stored in the Enterprise Blockchain Database and this is how we will know that the data has been changed and we cannot trust the Data and therefore we cannot use it for our Enterprise Business Processes.

On the other hand, if just before we load the data in to the SAP Enterprise Applications, eg SAP Asset Performance Management and SAP S/4HANA, from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our SAP Applications and we will have trustable Data.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise B2B Business Processes depends on Data being stored in the Enterprise Blockchain

But that's not the end of the b2B Business Processes need Enterprise Blockchain.

As we showed at the beginning of the blog in this picture:

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the in your DataCenter, in your Network on your SAP BTP Kyma Service AND we have an Enterprise Blockchain Database Tenant installed on your B2B Business Partner's Network, if they are a SAP Customer then like you they can put it on the SAP BTP Kyma Service, if not they can run it on Kubernetes.

The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from your DataCenter and Network where your S/4HANA is writing Data to it and stretches all the way across the Network to your Business Partner's DataCenter.

This means we have Enterprise Blockchain Data Protection from the source from your S/4HANA to the target your B2B Business Partner's It infrastructure enabling the trusted resilient reliable Business Processes to be completed.

At the same time, we are not exposing S/4HANA or the API's on the S/4HANA to any 3rd Party Applications.

We have digitally decoupled the S/4HANA from the Business Process.

And this is why we say, Enterprise Blockchain is a Secure Communication Channel, because instead of integrating Applications sending and replicating Data across Networks, we are sharing the Data across the Enterprise Blockchain and the Enterprise Blockchain is the Secure Communication Channel.

Enterprise Blockchain as a Shared Common Single Source of Truth for Master and Transactional Data across Organisations with SAP BTP and atkrypto.io

To conclude this section, the Why to, B2B Business Processes and Enterprise Blockchain, B2B Business Process Data needs to safely replicated and trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables B2B Business Processes to be both Secure, and Trustable.

And as we will see in the next section, it's not only about the Enterprise Blockchain being a common shared source of truth across Organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

Section 3.0: The How is it, of B2B Business Processes and SAP, and Enterprise Blockchain

The goal of this blog was to show how instead of using the legacy fire and forget approach of replicating data to 3rd Party Business Partners, the Enterprise Blockchain can be deployed as a common shared single source of truth running, with an Enterprise Blockchain Tenant running close to your S/4HANA and another Enterprise Blockchain Tenant running close to your Business Partner's Application.

In this section of the blog we will show all of the possible potential Technical Solution Architectures which will enable you to implement this next generation approach to sharing Data with the highest level of Cyber Security already today.

As described above one of the many beauties of this approach is your S/4HANA writes to the Enterprise Blockchain and your Business Partner's Application reads from the same Enterprise Blockchain. This achieves a number of things including:

. Total Control - you have total control over the Data you are sharing with the Business Partner, and you know that as long as your Business Partner's Application reads the Data from the common shared source, the Enterprise Blockchain

. Ultimate Cyber Security - then you know the maximum has been done to minimise the chance for Cyber Security risks and the maximum has been done to protect originality, integrity, and confidentiality of the Data

. S/4HANA Digitally DeCoupled from the Business Process - and on top of this, the S/4HANA has been digitally disconnected from the Business Process, because no longer do any 3rd Party Applications directly call API's on the S/4HANA

In the Technical Solution Archecture there would be two main ways for getting the data from the S/4HANA and writing it to the Enterprise Blockchain, these would be:

. API's

. Events

In these Technical Solution Architecture examples we will prioritise using S/4HANA Events to write the Data to the Enterprise Blockchain, we will be sending the Event Notification and the Event Payload, we could of course draw the same Technical Solution Architecture with API's, but we prefer the Events for the simplicity and reduced call backs to the S/4HANA and therefore making the S/4HANA more Digitally DeCoupled and therefore, enabling the S/4HANA to be protected to the higher security level and exposed to less Cyber Security risk.

Ok, let's go with the Technical Solution Architectures, in these examples we will focus on the OutSourced Payroll as the integration and B2B Business Process Example.

What do we have and what do we need:

Your Company will need:

. S/4HANA

. SAP EM and preferably SAP AEM since it has richer Security and Event Payload size capabilities and can Publish Events from Non-SAP Enterprise Applications and connect to your Enterprise Event Mesh

. SAP BTP

. SAP BTP Kyma Runtime Service - this is where the Enterprise Blockchain Container will run

. Enterprise Blockchain Platform Software which can run on Kubernetes

. If there will be larger Data objects then you will need Large Storage for Large Data and the Enterprise Blockchain Wallet in the form of SAP HANA Cloud (Data Lake)

Your Business Partner will need:

. Obviously their Payroll Application

. Either SAP BTP with Kyma Runtime, or Servers which can run Kubernetes Containers

. n.b. there is an Optional Technical Solution Architecture where you simply allow your Business Partner to read data from your Enterprise Blockchain where the Enterprise Blockchain Platform is running exclusively on your BTP, we will show that Option as well

Technical Reference Solution Architecture for SAP S/4HANA and SAP SuccessFactors and OutSourced 3rd Party Payroll Provider using Enterprise Blockchain as a Common Shared Single Source of Truth for Data and the Ultimate Cyber Data Security for B2B Business Processes...

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain atkrypto.io

In the next example, we have the same basic Technical Solution Architecture as the previous example, except, this Reference Use Case is ready for the Enterprise Blockchain needed to be able to handle large volumes of data and brings the Enterprise Wallet in to the picture. In the Enterprise Blockchain Platform the Enterprise Wallet storage is configurable and therefore could be SAP HANA Cloud (DataLake) or AWS S3 Buckets or other HyperScaler Data stores.

All of the other Cyber Security characteristics remain the same, S/4 is digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data, and the Enterprise Blockchain Tenants are running in both your DataCenter (AnyPremise) and the Business Partner's DataCenter (AnyPremise):

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain & Enterprise Wallet atkrypto.io

The next example Reference Technical Solution Architecture is a little bit different, let's assume, for their own reasons, your Business Partner is not going to run an Enterprise Blockchain Tenant in their (AnyPremise) DataCenter.

This is still fine, you will set up the Enterprise Blockchain Platform in your DataCenter(s) (AnyPremise) and your B2B Business Partner, in this case the outsourced 3rd Party Payroll Vendor will simply use API's to read and write to and from your Enterprise Blockchain.

All of the other benefits of the design remain the same, all of the other next generation Data sharing Cyber Security characteristics are still there, S/4 is digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data.

Here it is:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to your Enterprise Blockchain atkrypto.io

Finally, we have the same Reference Technical Architecture as above, but to be able to cater for large volumes of Data we include the Enterprise Wallet in the design:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise your Blockchain & Enterprise Wallet atkrypto.io

Ok let's wrap this up, the conclusions:

Ultimate Cyber Security for B2B Business Processes is Enterprise Blockchain, where the Enterprise Blockchain acts a common shared single source of truth for Data across Organisations

Enterprise Blockchain is:

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The next generation Integrations don't replicate Data, that's legacy, the next generation Integrations use Enterprise Blockchain as a common shared single source of truth.

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Data are stored safely and securely on the Enterprise Blockchain Database.

The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.

So what are we waiting for ? Oh yeah, deep dive in to more use cases, ok, that will be the next blog.

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.

Installing SAPRouter on Linux: A Step-by-Step Guide

2024-05-11T15:55:48.753000+02:00

What is SAP Router ?

SAPRouter is a software component used to secure communication between SAP systems and the internet. Installing SAPRouter on Linux is a crucial step in ensuring secure communication for your SAP landscape. This step-by-step guide will walk you through the installation process.

Prerequisites:

- Linux server (e.g., CentOS, Ubuntu)

- Root access to the server

- SAPRouter software package downloaded from the SAP Support Portal

Step 1: Download SAPRouter:

Download the SAPRouter software package from the SAP Support Portal. Ensure that you download the correct version for your operating system.

Step 2: Extract the SAPRouter Package:

Transfer the downloaded SAPRouter package to your Linux server. Use the following command to extract the package:

tar -xvf saprouter_<version>_linux_x86_64.tar.gz

Step 3: Create a Directory for SAPRouter:

Create a directory to store the SAPRouter files. You can use the following command to create the directory:

mkdir /usr/sap/saprouter

Step 4: Copy SAPRouter Files:

Copy the extracted SAPRouter files to the newly created directory:

cp -R <path_to_extracted_files>/saprouter /usr/sap/saprouter

Step 5: Create a Configuration File:

Create a configuration file named `saprouter.ini` in the `/usr/sap/saprouter` directory. Here's a basic example of the configuration file:

# SAProuter Configuration File

version = 39

httpport = 81

tracefile = /usr/sap/saprouter/saprouter.trc

authid = *

permit = *

Step 6: Set Permissions:

Ensure that the SAPRouter binary and configuration files have the correct permissions:

chmod 755 /usr/sap/saprouter/saprouter

chmod 644 /usr/sap/saprouter/saprouter.ini

Step 7: Start SAPRouter:

Start the SAPRouter using the following command:

/usr/sap/saprouter/saprouter -r -R /usr/sap/saprouter/saprouter.ini

Step 8: Verify SAPRouter Status:

Verify that SAPRouter is running and listening on the specified port (e.g., 81):

netstat -tuln | grep 81

Step 9: Configure Firewall:

Configure your firewall to allow incoming and outgoing traffic on the SAPRouter port (e.g., 81) to ensure proper communication.

Step 10: Configure SAP Systems:

Update the `secinfo` file of your SAP systems to include the SAPRouter details for communication through the SAPRouter.

Overall information:

By following these steps, you can successfully install SAPRouter on your Linux server. This will help secure communication between your SAP systems and the internet, ensuring the integrity and confidentiality of your SAP landscape.

#SAP #SAPRouter #Linux #Installation SAP Young Thinkers #Red Hat Enterprise Linux SUSE Linux Enterprise Server SAP Women in Tech SAP Integration Suite SAP Business Application Studio @Muthumayandi_Yadava @Subramanian @Sisn @YejinYun

Configuration as code (CaC) with destinations.

2024-05-13T12:54:57.123000+02:00

Configuration as code (CaC) with destinations.

Destinations are very handy and powerful mechanism to facilitate access to target systems and devices.

When it comes to SAP BTP destinations, the idea is to manage both subaccount and instance level destinations (and/or their certificates) as shared configuration resources on a provider subaccount level.

That way, the destinations configurations can be stored as versioned assets in a source repository and need to be maintained only once per provider, thus, without incurring application runtime tie-in.

Last but not least, BTP destination service is used as a self-configuration tool.

Configuration as code with SAP BTP destination service

Table of Contents

Configuration as code with SAP BTP destination service.

create shared destination service instance and binding.

Provision bootstrap destinations.

Configure destination resources.

Documentation.

PS.

Bootstrap destinations definitions.

Even, if there is no intrinsic BTP CLI command to assist in creation of destinations from service bindings, this can be achieved quite easily with a bit of jq gimmick by applying service binding credentials to a json payload template, for instance:

{
    "init_data": {
        "subaccount": {
            "destinations": [
                  {
                    "Description": "dest-httpbin",
                    "Type": "HTTP",
                    "clientId": "sb-clone12847c4c89544b4f9234b26ede429f62!b282590|destination-xsappname!b62",
                    "HTML5.DynamicDestination": "true",
                    "HTML5.Timeout": "60000",
                    "Authentication": "OAuth2ClientCredentials",
                    "Name": "dest-httpbin",
                    "tokenServiceURL": "https://<subdomain>.authentication.us10.hana.ondemand.com/oauth/token",
                    "ProxyType": "Internet",
                    "URL": "https://httpbin.org",
                    "tokenServiceURLType": "Dedicated",
                    "clientSecret": "<clientSecret>"
                  },
                  {
                    "Description": "SAP Destination Service APIs",
                    "Type": "HTTP",
                    "clientId": "sb-clone12847c4c89544b4f9234b26ede429f62!b282590|destination-xsappname!b62",
                    "HTML5.DynamicDestination": "true",
                    "HTML5.Timeout": "60000",
                    "Authentication": "OAuth2ClientCredentials",
                    "Name": "destination-service",
                    "tokenServiceURL": "https://<subdomain>.authentication.us10.hana.ondemand.com/oauth/token",
                    "ProxyType": "Internet",
                    "URL": "https://destination-configuration.cfapps.us10.hana.ondemand.com/destination-configuration/v1",
                    "tokenServiceURLType": "Dedicated",
                    "clientSecret": "<clientSecret>"
                  }
            ],
           "certificates": [
           ],

            "existing_certificates_policy": "update",
            "existing_destinations_policy": "update"           
       }
   }
}

Alternatively, one could resort to using SAP Cloud SDK built-in service binding destinations.

The below nodejs code snippet demonstrates how to leverage SAP Cloud SDK with its service binding destinations with the likes of service manager and destinations services.

apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
  name: {{ .Values.services.srv.name }}
  labels:
    {{- include "app.labels" . | nindent 4 }}
    app: {{ .Values.services.srv.name }}
spec:
  runtime: {{ .Values.services.srv.runtime }}
#  runtimeImageOverride: {{ .Values.services.srv.runtimeImageOverride }}
  source:
    inline:
      dependencies: |
        {
          "name": "{{ .Values.services.srv.name }}",
          "version": "0.0.1",
          "dependencies": {
            "axios":"latest"
            ,"debug": "latest"
            ,"@sap/xsenv": "latest"
            ,"@sap-cloud-sdk/http-client": "latest"
            ,"@sap-cloud-sdk/connectivity": "latest"
            ,"@sap-cloud-sdk/resilience": "latest"
            ,"async-retry": "latest"
          }
        }
      source: |
        const debug = require('debug')('{{ .Values.services.srv.name }}:function');
        const NOT_FOUND = 'Not Found';
        const xsenv = require('@sap/xsenv');

        const services = xsenv.getServices({
          sm: { label: 'service-manager', name: 'saas-sm' }
          ,
          dest: { label: 'destination' }

        });
        console.log('saas-sm: ', services.sm);

        const readServices = xsenv.readServices();
        console.log('readServices: ', readServices);

        const httpClient = require('@sap-cloud-sdk/http-client');

        const cloudSdkConnectivity = require('@sap-cloud-sdk/connectivity');
        const { retrieveJwt, decodeJwt, Destination } = require('@sap-cloud-sdk/connectivity');
        const { setGlobalLogLevel, createLogger } = require('@sap-cloud-sdk/util');
        const { retry } = require ('@sap-cloud-sdk/resilience');
        const { resilience } = require ('@sap-cloud-sdk/resilience');
        const ResilienceOptions = {
          retry: 10,
          circuitBreaker: false,
          timeout: 300*1000 // 5 minutes in milliseconds
        };          

        const retryme = require('async-retry');

        setGlobalLogLevel('debug');
        const logger = createLogger('http-logs');

        module.exports = {
          main: async function (event, context) {
            const req = event.extensions.request;

            const message = `Hello World`
              + ` from the Kyma Function ${context['function-name']}`
              + ` running on ${context.runtime}!`
              + ` with the request headers ${JSON.stringify(req.headers,0,2)}`;
            console.log(message);
            
            if (typeof req.path !== undefined) {
              console.log('path: ', JSON.stringify(req.path,0,2))
            }
            if (typeof req.params !== undefined) {
              console.log('params: ', JSON.stringify(req.params,0,2))
            }
            if (typeof req.url !== undefined) {
              console.log('url: ', JSON.stringify(req.url,0,2))
            }
            if (typeof req.authInfo !== undefined) {
              console.log('authInfo: ', JSON.stringify(req.authInfo,0,2))
            }

            const { pathname } = new URL(req.url || '', `https://${req.headers.host}`)
            console.log('pathname: ', pathname)

            const url = require("url");
            var url_parts = url.parse(req.url);
            console.log(url_parts);
            console.log(url_parts.pathname);

            // returns an array with paths
            let path_array = req.url.match('^[^?]*')[0].split('/').slice(1);
            console.log(path_array)

            console.log(req.url.match('^[^?]*')[0])

            if (!path_array?.length) return 'Please use an API verb';  
            const actions = [ 
               { name: 'offerings', verb: 'service_offerings', dest:  'saas-sm', url: '/v1/' },
               { name: 'plans', verb: 'service_plans', dest:  'saas-sm', url: '/v1/'  },
               { name: 'instances', verb: 'service_instances', dest:  'saas-sm', url: '/v1/'  },
               { name: 'bindings', verb: 'service_bindings', dest:  'saas-sm', url: '/v1/'  },
               { name: 'instanceDestinations', verb: 'instanceDestinations', dest:  'faas-dest-x509', url: '/destination-configuration/v1/'  },
               { name: 'subaccountDestinations', verb: 'subaccountDestinations', dest:  'faas-dest-x509' , url: '/destination-configuration/v1/' }
            ];
            
            const action = actions.find( ({ name }) => name === path_array[1] )
            console.log('action found: ', action)

            if (path_array[0] == 'srv' &&  action !== undefined) {

              path_array = req.url.match('^[^?]*')[0].split('/').slice(2);

              console.log('path_array: ', path_array)

              const queryString = req.query;
              console.log('queryString: ', queryString)
              const urlParams = new URLSearchParams(queryString);

              const params = req.params;
              console.log('params: ', params) 

              try {
                  // https://sap.github.io/cloud-sdk/docs/js/features/connectivity/destinations#service-binding-environment-variables
                  const endpoint =  path_array[1] !== undefined ? '/' + path_array[1] : '';
                  console.log(endpoint)
                  let res = await httpClient.executeHttpRequest({ destinationName: action.dest }, {
                      method: 'GET',
                      url: action.url + action.verb + endpoint
                  });
                  return res.data;
              } catch (err) {
                  console.log(err.stack);
                  return err.message;
              }
              
            }            
          }
        }
   scaleConfig:
    maxReplicas: 5
    minReplicas: 3
  resourceConfiguration:
    function:
      profile: S
  env: ## https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-configuration-parameters/svls-02-environment-variables/#node-js-runtime-specific-environment-variables
    - name: FUNC_TIMEOUT ## Specifies the number of seconds in which a runtime must execute the code.
      value: '1800'
    - name: REQ_MB_LIMIT ## payload body size limit in megabytes.
      value: "10"

    - name: DEBUG
      value: '{{ .Values.services.srv.name }}:*'
    - name: SERVICE_BINDING_ROOT
      value: /bindings
    

  secretMounts: 
    - secretName: {{ .Values.services.sm.bindingSecretName }}
      mountPath: "/bindings/saas-sm"
    - secretName: {{ .Values.services.dest.bindingSecretNamex509 }}
      mountPath: "/bindings/faas-dest-x509"

RingFencing & DeCoupling S/4HANA with Enterprise Blockchain and SAP BTP - Ultimate Cyber Security 🚀

2024-05-14T13:56:58.227000+02:00

tl;dr

As part of S/4HANA Transformation Programs, Security, Accessibility, Resilience are being re-imagined.

The going in position for a lot of S/4HANA Transformation Programs includes the Cyber Security principles:

Only Employees will have direct access to the Digital Core as End Users
There will be no direct access to the Digital Core by 3rd Party Applications

The first principle, 'Only Employees will have direct access to the Digital Core as Users', decoupling the SAP system for External Users has been an architectural design pattern for more than a decade. For example, due to the extremely sensitive and confidential nature of Product LifeCycle Management Data, 13 years ago SAP were advocating, building an empty SAP PLM system in the DMZ which would use RFC's to communicate with the actual SAP PLM system in the Secure Network Zone:

The beauty of this design is that it decouples End User Access from the core SAP PLM system, therefore enhancing the security protection of the SAP PLM system.

Today's equivalent of that is to put the SAP Build Work Zone Launchpad in front of the S/4HANA Digital Core.

That is fine, that means the Digital Core is digitally decoupled for End Users, but what about Machine to Machine, Application to Application, 3rd Party Applications which want to get Data from the S/4HANA ?

Do you really want 3rd Party Companies calling APIs on your Digital Core - atkrypto.io

When a 3rd Party Company calls an API on your S/4HANA Digital Core, you are replicating your Data to that 3rd Party Company.

How can the S/4HANA Digital Core be decoupled when 3rd Party Applications need to get Data from the S/4HANA, how can the S/4HANA Digital Core be architected in such a way that there are no Machine to Machine calls directly to the S/4HANA for the purpose of getting Data ?

As elaborated in more detail in a previous blog, API's enable your Data to be replicated to 3rd Party Applications which can also be in 3rd Party Partner Companies, and this brings a set of problems centered around:

As ever, the pattern is the same, the theme is the same,

it's all about the Data

what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data

Ring Fencing S/4HANA raises the Cyber Security by reducing the attack surface.

The most secure way is with Enterprise Blockchain as a Data Ring Fence around the S/4HANA Digital Core, therefore digitally decoupling access and integration of the S/4HANA Data from other Applications.

The Enterprise Blockchain is:

. Ring Fencing of the S/4HANA

. S/4HANA does not expose API's directly to any 3rd Party Companies

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The S/4HANA Ring Fencing with Enterprise Blockchain as a shared single source of truth could involve the Enterprise Blockchain running on your SAP BTP Kyma Runtime and at the same time running on Kubernetes Servers in your Business Partner's Data Center:

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

Or alternatively the S/4HANA Ring Fencing with Enterprise Blockchain could be where the Enterprise Blockchain is running on your SAP BTP Kyma Runtime and your 3rd Party Business Partner Company reads the Data from your Enterprise Blockchain on your SAP BTP Kyma Runtime as a shared common single source of truth for the Data:

S4HANA RingFenced by your own Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

Read on for the full story... 🚀

Introduction

The reason I am so interested in this is I have been securing availability and accessibility of SAP systems for the last 25 years, and back in 2013 I wrote this blog about "Alternatives for Securing Internet Facing Applications".

There is so much to talk about on this subject, let's get in to it. Back in 2013 at a Customer, we were looking at Ring Fencing critical systems.

Back then the focus was on DeCoupling the SAP system where End User access was required from people coming in from the Internet, infact the reasons for the RingFencing were centered around:

Access - Authentication & Authorisation
Storage of Data
Communication Channels
DeCoupling especially for Internet Collaboration

The DeCoupling for Internet Collaboration was based around SAP's SAP PLM Reference Architecture,

and the SAP PLM Technical System Landscape recommendation:

Fast forward to today, and SAP Customers have the luxury that the worry of securing End User Internet Access to their SAP systems is outsourced to SAP through the implementation of the SAP BTP Build Work Zone Launchpad. It should not go unnoticed that when you implement the SAP BTP Build Work Zone Launchpad Service, you also don't have to care for Web Access Firewalls and the Security of Internet Access.

But what about API's, what about System to System, Machine to Machine ? What about Integrations ? What about when Non-SAP Applications in your Company or other Companies need data from the S/4HANA ?

S/4HANA has a rich collection of API's which is always growing, but, should Applications from your Partner Companies call API end points on the S/4HANA Digital Core ?

Should 3rd Party Applications, and 3rd Party Partner's Applications be directly accessing the Digital Core S/4HANA API's ?

Regardless of whether the S/4HANA is an [Any]OnPremise, S/4HANA RISE Private Cloud Edition, S/4HANA Public Cloud Edition, should 3rd Party Applications be allowed to directly call API's on your S/4HANA ?

Let's take the S/4HANA Business Partner API, should Applications from your Partner Companies be allowed/able to call this API on your Digital Core S/4HANA to retrieve changes to Business Partner Data ?

Legacy API Integrations calling S4HANA API and Replicating Data to 3rd Party Company Applications - atkrypto.io

If you have doubts or think the answer is no, then read on, there is a solution, it is very nice, and very easy, and very secure.

One of the biggest Cyber Security threats to your Data and therefore your Operations and therefore your Business, is allowing 3rd Party Applications from 3rd Party Companies to call Data from API's on your S/4HANA Digital Core, and then, replicate your Data to Servers in their Company.

As ever, the pattern is the same, the theme is the same,

it's all about the Data

what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data

Like the other blogs in this series, this blog is going to break the subject down in to three sections:

Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Section 3.0: The How is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

In case you missed them, the previous blogs in this series are here:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT 🚀

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP 🚀

Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

What is RingFencing ? There is a very nice description here:

RingFencing is about isolating Data, away from the most important SAP system, the S/4HANA Digital Core.

DeCoupling, the word DeCoupling has a number of meanings in Enterprise IT. What we are talking about here in the case of the S/4HANA Digital Core and Data access by 3rd Party Company Applications is that we are DeCoupling the Data access away from directly on the S/4HANA, by DeCoupling we are making the S/4HANA Data indirectly accessible.

It can be thought that if we are RingFencing, or Isolating, or DeCoupling the S/4HANA Data away from the S/4HANA then we are creating another copy of the Data, another Replica of the Data, which is true, we are, and that is the same as when Data is replicated to 3rd Party Systems via API, whichever way you look at it, the ultimate goal is a Replica of the S/4HANA Data which is available and accessible to the 3rd Party Company Application for the reasons of that Application of Business Transaction.

We can replicate the Data using an S/4HANA API to the 3rd Party Company Application and lose all control of the Data and also have to deal with how to secure Authentication and Authorisation and Network Access to the API, or we can replicate to our own RingFenced isolated trusted location.

SAP S4HANA RingFenced DeCoupled Data Cyber Security Principles - atkrypto.io

What about the Enterprise Blockchain, what is Enterprise Blockchain ?

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. RingFencing is about isolating and protecting Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Why would we want to RingFence and DeCouple S/4HANA, the Digital Core from 3rd Party systems which legitimately need S/4HANA Data ?

The answer is simple, Cyber Security, Cyber Threats.

Not so long ago, the focus was on High Availability and Disaster Recovery, the biggest threat was the system going down and not coming back.

Today, things have changed, and the biggest threat is a malicious actor rendering our business Data unusable.

Today we know we can buy new servers, we know we can get a Data Center up and running, but how do we repair Data which has been maliciously rendered unusable ? Think about the Ransomware attack.

So what is ring fencing and why do we need to do it ?

Ring Fencing is about reducing exposure to Cyber Threats.

What are the biggest easiest ways that we can reduce exposure to Cyber Threat ?

Stop 3rd Party Companies from calling API's on the S/4HANA Digital Core.

Stop publishing API's for 3rd Party Application access on the S/4HANA Digital Core.

Stop doing this: