DEV Community: Michal Šrámek

The Magic of SAP: A Comprehensive Guide for Begginers

Michal Šrámek — Wed, 26 Jun 2024 21:10:50 +0000

In the process of our IT life, each of us will surely encounter the word SAP one day. But what is actually SAP and how does it actually work? The official vendor documentation is clear on this and defines SAP as following: SAP is one of the world’s leading producers of software for the management of business processes. That is not entirely clear. Even a literal German translation - Systemanalyse Programmentwicklung - will not help us too much.

SAP is basicly collection of Systems, Applications, and Products in Data Processing. It is provider of enterprise software solutions designed to enhance business processes and efficiency. One of SAP's key products is so-called SAP ECC (i.e. ERP Central Component), with extra indication R3, which refers to its architecture based on Real-Time data processing and a three-tier structure.

This architecture includes the presentation layer, application layer, and database layer, working together to provide robust, scalable, and flexible Enterprise Resource Planning (ERP) solutions that support a wide range of business functions.

Presentation Layer

The presentation layer in SAP R3 architecture is crucial for facilitating user interaction with the system. This layer provides input capabilities for users to manipulate the system and output functionalities for generating results based on user actions. The primary interface for users interacting with SAP applications is the SAP GUI, which is installed on individual machines. Through SAP GUI, users can access various SAP modules and execute transactions, run reports, and perform data entry tasks. The presentation layer ensures a seamless and intuitive user experience, translating complex backend processes into comprehensible visual elements, thereby enhancing user productivity and system usability.

Application Layer

The application layer serves as the core of the system, processing business logic and managing communication between the presentation and database layers. A key component of this layer is the Web Dispatcher, which acts as a critical gateway between the Internet and SAP systems. It handles HTTP(s) requests, balances the load across multiple SAP NetWeaver application servers, and enhances system security by filtering URLs and supporting SSL encryption. The Web Dispatcher is compatible with both pure ABAP (high-level programming language cretaed by SAP) and Java systems.

Within the application layer, various ABAP Processes are essential for efficient system operations:

Dialog Process (DIA): Manages the interaction between the user and the system, handling immediate transaction requests.
Background Process (BGD): Executes long-running or scheduled tasks that do not require real-time user interaction.
Spool Process (SPO): Manages print requests and the overall printing process.
Update Process (UDP): Responsible for updating data in the database, ensuring that changes are correctly saved.
Enqueue Process (ENQ): Handles the locking of data to maintain consistency and integrity during concurrent access.

Additionally, the application layer includes crucial ABAP Services:

Message Service: Ensures load balancing across different SAP server instances, routing and delivering messages efficiently.
Enqueue Replication Server (ERS): Maintains a synchronized replica of the lock table on a secondary NetWeaver server, ensuring data consistency and enabling automatic failover in the event of a primary server failure.

Together, these components and services ensure that the application layer functions effectively, supporting robust and reliable enterprise resource planning for businesses.

Database Layer

The database layer is responsible obviously for storing and retrieving data, forming the foundation of the entire system. While SAP does not provide its own database system, it supports integration with leading relational database management systems (RDBMS) such as Oracle, DB2, and HANA. HANA, a multi-model database, is particularly notable for its ability to store data in memory rather than on a disk, which significantly enhances processing speeds compared to traditional database management systems.

HANA's integration includes High Availability and Disaster Recovery (HA/DR) capabilities through so-called HANA System Replication (HSR). This mechanism ensures high availability by automatically switching to a standby host in case of a primary host failure. It uses synchronous data replication to maintain data consistency between the primary and standby hosts, thus minimizing downtime and ensuring data integrity.

This layer's robustness is critical for the overall performance of the SAP system, as it handles large volumes of transaction data, supports complex queries, and ensures data integrity and security. The database layer's compatibility with top-tier relational database management system (RDBMS) and advanced features like HANA's in-memory storage and HSR replication make it a powerful component of the SAP ECC R3 architecture, enabling businesses to process and analyze data with exceptional speed and reliability.

Trivia

The following abbreviations are also associated with SAP:

PAS = Primary Application Server.
AAS = Additional Application Server.
ASCS = ABAP Central Services (core of the SAP application service)

The differences between PAS and AAS:

The PAS contains the ASCS, but an AAS does not.
In a system, there is only one PAS, but there can be multiple AASs. The number depends on the service requirements.

Conclusion

SAP stands globally as a leading provider of enterprise software solutions, helping organizations streamline and optimize their business processes. With its robust architecture and integration capabilities, SAP enables efficient management of complex operations, enhancing productivity and decision-making. SAP's adaptability with various database systems and its advanced features ensure it remains a vital tool for businesses aiming for growth and operational excellence.

Fortress GitHub: Building a Secure Organization

Michal Šrámek — Mon, 08 Apr 2024 07:43:58 +0000

Authentication security on the GitHub platform is a key aspect of protecting corporate data and securing user accounts. Usually, we rely not only on standard methodologies (passwords, 2FA) but also on the significant benefits of centralized access control and easy integration with an external identity service. In this way, we could contribute to an overall increase in the level of security. SAML (Security Assertion Markup Language) is a standard for exchanging authentication and authorization data between security domains, often used for Single Sign-On (SSO) across web applications. In the context of GitHub, it's important as it allows centralized access control and easy integration with external identity services, enhancing overall security.

Before implementing SAML protocol on the GitHub platform, several key requirements should be met.

Regions Separated by Root Teams

In an international organizations integrated inside one big GitHub Enteprise, it is important to separate the different regions (resources) with a specific team that will have a root responsibility.

Each unique root team should have the opportunity to participate in decision-making (global PR related to the region) concerning the specifics of the region (technology, business, etc.).
Other development teams corresponding to their region should be always nested within a root team and should not exist outside their team (including users).

External partners (helping with migrations, quality assesment etc.) should be in the namesake group and their access should be explicit, limited, and valid only for the repository invitation (see below).

Disabling Outside Collaborators

It is practically unacceptable for anyone with admin rights in a repository to have permission to add Outside Collaborators to that repository. Disabling these Outside Collaborators on an organization-wide level is an important step toward securing and protecting the organization's sensitive data and resources. This measure will minimize the risk of unauthorized access and misuse of information by those outside the organization.

There should be no Outside Collaborators at the organizational level. Any potential Outsiders must go through internal company HR system to gain access in the same way as internal members.

Related: Outside Collaborators should not be able to request access to GitHub or OAuth applications to access any organization and its resources.

Base Permission for Organization

At the GitHub organization level, it is important to correctly select the Base Permissions of members. The most commonly, the Read method is selected (users are allowed to clone and download repositories). The permissions in GitHub, like the RBAC policy of any other system, should be as strict as possible (especially if the company is in the Cloud, where is applied shared responsibility) and should only provide the permissions that are necessary for each specific user. An important step to strengthen security in a multi-region approach is to change the organizational base permissions from Read to No permissions.

This step eliminates the implicit access of all members to the organization and replaces it with explicit access at the repository level. Support for explicit access allows the organization to flexibly set and manage access rights in accordance with security policies. The organization gains greater control over who has access to individual resources and minimizes the risk of unauthorized access, data misuse, and reduces the risk of security incidents.

Users are not be blocked from collaborating in this way, they will need just add/remove and fine-tune the correct access of other teams to their repositories (see below).
The principle of least privilege is respected.

More information is provided by this article.

Collaboration at Team Level

Collaborating on GitHub in teams is an organized approach to working on projects. Teams allow for grouping members (using other teams), managing permissions, communicating, and sharing responsibilities. It also enhances transparency, as all team members have access to the same resources and information. The team structure should be designed to reflect the organization's structure and business processes.

Teams are repository owners, not individuals (common security goal).
Collaboration and approval of PR should be at the team level, not on individual level.

The creation of Ad Hoc Teams should be prohibited at the organization-wide level. Every team that needs to exist in a GitHub organization should be first processed through internal company system (e.g. Active Directory). Such a change should be then reflected in GitHub.
Once SAML is enforced, GitHub will automatically synchronize team members with the corresponding group structure according to used IdP.

Repository Protection

Repository Creation

The process of creating a repository is the first step to organizing and sharing code and projects with the team. It is important not only to set permissions correctly to ensure that only appropriate team members have access to the repository (see above), but also to implement a policy. There are currently 3 types of repositories that can be created in the enterprise version of GitHub:

Private (visible to organization members with permission).
Internal (visible to all members of the enterprise organization = among other regions).
Public (visible to anyone from the internet).

Private repositories are a key part of maintaining the integrity of the internal development process and should be established as a matter of priority.

All members of the Enterprise organization have access basically to all repositories created as Internal. Permissions can be changed within the Enterprise, it is not easy to assess at Organisation level who all has such permissions. Therefore, it is worth considering whether to create Internal repositories and the responsibility should belong to each team.

Public repositories should be gradually banned at the level of the GitHub Enterprise. A separate organization should be created within GitHub Enterprise, where a public license and policy should be properly created to manage such repositories. Thus, in exceptional and justified cases, a Public repository may be created, but outside of the each regions in dedicated GitHub Organization.

Repository Default Branch

Default Branch Protection Rules are essential to ensure the integrity and security of code in various forms of shared repositories. The rules allow us to define levels of protection, including mandatory rules for change approval or protection against direct upload to a branch that is to be used exclusively for deployment (Trunk Based Development) to the Cloud.

Because automation is a key part of the development process, it is important to ensure that the rules are set correctly and that the automation is properly configured. It is possible to use GitHub Actions to create PRs. However, this also has some risks and therefore in all repositorie should be required at least 1 person for approval of the PR → For this reason, CODEOWNERS should be properly defined in each repository to prevent automatic merges to the release branch without the repository owner's knowledge.

Code owners are always a team in the organization (see above), or even a team other than the one that owns the repository can be defined. However, such a team must then have WRITE rights to the repository.

GitHub Actions may create PRs, but they may not automatically approve them.
There should be a CODEOWNERS file in each repository.
Gradually the protection of the default (release) branch should be enforced by introducing the Organizational Ruleset and monitored scraping the Audit Logs.

Conclusion

The implementation of the SAML protocol on the GitHub platform is a key step in enhancing the security of the organization. However, it is important to ensure that the organization's structure and processes are properly designed and that the necessary security measures are in place. The organization should be structured in such a way that it reflects the business processes and that the team structure is designed to ensure that the organization's resources are properly managed and protected. The implementation of the SAML protocol should be accompanied by the implementation of the necessary security measures, such as the protection of the default branch, the protection of the repository, and the protection of the organization's resources. The implementation of these measures will help to ensure that the organization's resources are properly managed and protected, and that the organization's data is properly secured.

GitHub: Personal Access Tokens

Michal Šrámek — Thu, 04 Apr 2024 08:12:25 +0000

There are currently 2 types of personal access tokens (PATs) available on GitHub. Fine-grained PATs (beta) and Classic PATs. Both are used for authentication and authorization, but have different properties and uses. There is no Token like Token.

	Fine-grained PATs (beta)	Classic PATs
Purpose	Token for GitHub API for scripting or testing.	OAuth personal access tokens OR Instead of a Git password via HTTPS OR For API authentication via Basic Authentication.
Expiration	Required (up to 1 year)	Can be used without expiration.
Owner	User and also Organization	User
Access	Either repository permissions (public, all, selected) and may (may not) access resources under the personal account; OR repository permissions (public, all, selected) and may (may not) access resources under the organization	Determined by Scopes. These can be for anything the user is entitled to (even within the Organization).
Overview	They are visible in the Organization in the "Active tokens" overview with a visible expiration date. Once clicked, the accesses (what permissions the token has in which repository) are clearly visible.	There is no overview in the Organization. It is possible to retrieve token activity via the API, but we cannot distinguish user activity from machine activity. Their activity is only recorded in GitHub Audit Logs.
Can PAT be disabled?	Yes	Yes
Is approval required?	Yes and No	No

Active use of Fine-grained PATs

If the GitHub Organization Member (not the Owner) chooses to use Fine-grained PATs and mandatory approval of Fine-grained PATs is enabled, the Member will receive a "not found" message and the request will be in pending status. It will also appear in the "Pending Requests" report in the Organization:

The GitHub Organization Owner can judge whether the access is justified or not and approve/deny the request (or instruct the Member to restrict the rights of his PAT):

This way least privileges can be demanded and access is under control. Member will receive the approval/denial result via email.

With disabled approval, the PAT is visible in the overview of active PATs, but there is no Organization Owner control over accesses.

If a Member delete their PAT, no Owner approval is required, the PAT simply disappears from the list of active PATs.

If a Member changes the rights of an already approved PAT, it needs to be re-approved (correct and expected approach).

With Classic PATs there is no overview of who and how many are actually using them. Through the API it is possible to get some information, but it is no longer possible to distinguish between a machine and a Member (all activities are pretending to be Member activities).

The risks of using PATs

The use of PATs within the GitHub Organization exposes the Organization to some potential risks:

Broad permissions: If the PAT grants wide permissions (e.g. administrative rights to everything in the Organization), a Member or application with this token can perform a wide range of actions, including those that may harm the Organization.
Loss of token: If the PAT is in the wrong hands, it can be misused. Depending on the permissions of the token, this can mean loss of data, modification of repositories, etc.
Expiration: Classic PATs on GitHub do not need to have any expiration (see table). This means that if a PAT is compromised and no one notices, it can be misused for a long time.
Audit: Although actions performed using PAT can be recorded, it can be harder to distinguish who actually performed the action if multiple people or systems share the token.
Management: With multiple PATs created it can be harder to keep track of who created what PAT, why and where it is used -> especially in the case of Classic PATs that are not visible in the active PAT overview (see table). This is a significant complication for security management.
Function of systems: A Member who builds a functional system/application on his/her personal PAT within his/her team and changes employment in the future, the rest of the team (or possibly the Organization) will no longer be able to use the automation/system/application. Upon leaving GitHub, the Organization will lose its PAT rights.

What GitHub Support says

Fine-grained PATs have similar access restrictions as GitHub Apps.
Classic PAT has the most capabilities of all the verification methods.

Adding repository to the GitHup App would not help, because it has unsupported endpoint for Fine-grained PAT. Managing GitHub Apps has always been seen as something that requires a human to be involved because of the potential for improper access. GitHub is also getting feedback on Fine-grained PATs (they are in beta) in discussion. Anyone interested in using Fine-grained PATs for GitHub Apps and their repository management can have their voice heard here.

Replacement for PATs

Unless a specific case requires it, the use of PATs within the GitHub Organization should be avoided at all costs (especially classic ones), see Risks above. There are different authentication and authorization solutions for different tasks and integrations:

OAuth App - Allows you to grant a specific application access to specific resources with specified permissions. In addition, access can be revoked at any time.
GitHub Apps - the most preferred way to integrate with GitHub. They can only access the information they need (least privileges) which increases security.
Deploy Keys - only for specific repositories, for authentication. These are SSH keys that bind to exactly one repository and allow reading or writing.
Webhooks - for notification of certain events occurring in the Repository or the Organization. Not functional with applications running on-premise.

Apparent Solution

PAT's are unfortunately another thing which is being left very often in an uncontrolled situation due to nobody really is responsible for it. There is no definite "best practise" approach. One thing is recommended - only the newer fine-grained PATs with enforced approval should be allowed to GitHub Organization Members. This way, the Organization Owner can control the accesses and ensure that the principle of least privileges is respected. The use of Classic PATs should be avoided as much as possible and left as a privilege only for the Organization Owners and their GitHub management.

Activity Monitoring and Audit in AWS

Michal Šrámek — Wed, 03 Apr 2024 12:30:57 +0000

Following text involves AWS native tools for the continuous monitoring of activities within an AWS environment to detect and respond to security threats and breaches.

It encompasses the discovery collection of best practices, how to achieve this goal. Implementing this secure Activity Monitoring and Audit in AWS, will enhance security posture, mitigate risks, and better protect all AWS resources and sensitive data from unauthorised access or malicious activities.

Every decision made in AWS environment should be in accordance with the AWS Security Reference Architecture. This involves understanding the principles outlined in the architecture, conducting a risk assessment to identify potential security risks, and designing AWS architecture to incorporate security controls at every layer.

Framework

I personally recommend "internal audit framework" which is in compliance with AWS and should include the following (16) steps:

Start to use AWS Landing Zone with AWS Control Tower (AWS Organizations)
- AWS Landing Zone primarily sets up the initial infrastructure (multi-account AWS environment, core infrastructure components like networking and IAM). AWS Control Tower provides ongoing management and enforcement of security and compliance controls (centralised governance, compliance capabilities and enforcing policies across entire AWS environment). AWS Organizations is the underlying AWS service of AWS Control Tower.
Turn on AWS CloudTrail in each AWS account
- AWS CloudTrail logs can be analysed in real-time to detect unauthorised access attempts or changes to critical resources. Integration with monitoring tools enables proactive threat detection and compliance monitoring across the AWS environment.
Store AWS CloudTrail log in a centralised logging account with very restricted access
- Proper stream log management and analysis processes enable more efficient threat detection and incident response. Restricting access to the centralised logging account minimises the risk of unauthorised access, ensuring data confidentiality and integrity.
Create AWS CloudWatch alarms for specific API calls
- Real-time notification alarms of critical events for specific API calls (high-volume data transfers, sensitive resource modifications) should be enabled. These alarms serve as proactive measures. AWS CloudWatch Logs Insights can also search API history beyond the last 90 days. Additional useful info HERE.
Use Logging IP traffic for VPCs and DNS logs
- Obtaining valuable informations using VPC Flow Logs and Amazon Route 53 resolver query logs and streaming them to either an Amazon S3 bucket or a CloudWatch log group is crucial.
Periodically examine “AWS log files” with AWS GuardDuty
- This process enhances activity monitoring in AWS by proactively identifying security threats and suspicious activities. AWS GuardDuty can automatically analyse threat detection of AWS CloudTrail Events, VPC Flow Logs, DNS Logs and generally alerts to unexpected activity.
Enable AWS S3 buckets logging to monitor requests made to each bucket
- It allows to monitor requests made to each bucket and track access attempts, changes, and other activities. Analysing S3 access logs can help identify unauthorised access attempts, data breaches or misconfigurations.
Use AWS Config for viewing historical IAM configuration and changes over time
- AWS Config is enabling to view the IAM policy that was assigned to a user, group, or role at any time. It is basically resource inventory (existing as well as deleted).
Collect alerts for IAM configuration changes and their audits
- By setting up alerts we can be notified on IAM configuration changes. Additional useful info HERE.
Set up AWS Detective controls around user creation and using a user credentials
- It is need to be implemented together with AWS Config when a new user or group is created and for any API actions performed by a non-federated IAM principal.
Periodically generate and download IAM credential report
- Report can be used to audit the effects of credential lifecycle requirements (lists all users, status of their passwords, access key updates and MFA devices). It can be further reported to an external auditor.
Check regularly the AWS IAM Access Analyzer
- Achieving least privilege and grant the right fine-grained permissions. It provides capabilities to set, verify, and refine permissions, analyse external access and validate, that policies match corporate security standards.
Audit session activity using AWS EventBridge
- Set up rules to detect when changes happen to any AWS resources. It provides comprehensive visibility into user actions and system events.
Enable the session activity logging in AWS Systems Manager
- Continual stream of session data logs to AWS CloudWatch Logs with details (user’s commands in a session, the ID of the user and timestamps). Additional useful info HERE.
Use AWS Access Advisor to refine set up permission guardrails
- It analyses last accessed information in AWS accounts. Permission guardrails help control which services users and applications can access and determine the services not used by IAM users and roles. With service control policies (SCPs), access to those services can be restricted.
Automatically collect and monitor evidence by AWS Audit Manager
- Proactive measure reducing risk by fine-tuning AWS controls. Evidence is a record that contains the information needed to demonstrate compliance with the requirements specified by a control. Examples of evidence could be a change activity triggered by a user, or a system configuration snapshot.

Conclusion

Implementing the above framework will help to ensure that the AWS environment is secure and compliant with security best practices. It will also help to detect and respond to security threats and breaches in a timely manner. By continuously monitoring activities within the AWS environment, organisations can better protect their resources and sensitive data from unauthorised access or malicious activities. The information as well as the mentioned framework is in compliance with the Czech Act on Cyber Security No. 181/2014 Coll. and the Decree on Cyber Security No. 82/2018 Coll.