External service security issues
For example, SOA applications may rely on web-based third-party services to provide important functions and services, which has obvious security problems. However, this problem has existed since enterprise users activated Microsoft automatic update.
Fundamentally speaking, this is a question of trust, such as whether you decide to trust the update program sent to you by Microsoft. SOA may greatly increase the frequency of using external services, and hundreds of such interactions may occur in an hour.
Some malicious websites pretend to provide a certain function or service, deceiving some people into deciding to trust it. Malware is usually disguised as useful code, and sometimes it provides some promised functions, but at the same time it is quietly doing things that users don't want.
This is one of the three main security impacts that SOA may bring to enterprises. Fighting against malware requires comprehensive technical and educational strategies. Whether it is SOA-related behavior or someone in the enterprise downloading "free" music from a file sharing website, these behaviors must be restrained. This security technology can successfully stop malware before it infects the enterprise network. But the best solution is to educate users to be aware of security risks and let them know the dangers of unknown websites, so as to minimize the risks in the first place.
The XML file carries the attack code.
The second major flaw occurs in the use of XML files by enterprises, which is more technical and difficult to intercept. Fundamentally speaking, XML can contain any kind of data or executable programs, including those that are deliberately destroyed. Today, most enterprises are already using XML-encoded files, so they are not protected.
However, SOA will definitely increase the number of XML transmissions by an order of magnitude, which means an increase in security flaws. A large number of such transmissions in SOA architecture also make it difficult for IT personnel to intercept occasional malware. In addition, the increasingly complex malware technology has clearly told us that attackers can use XML.
In solving this security risk, education has little effect, because it is more likely to be injected into a legal data packet and enter the enterprise network, and may even divide itself into several parts and mix them in different legal communications. The user may not have done anything wrong. There are more and more such targeted attacks.
However, products that can solve this problem have appeared. Cross beam and forum form an alliance, combining X series security service switch of cross beam, Xwall Web service firewall of forum and forum sentry Web service gateway to launch a single best solution to intercept malicious software in XML and other data streams entering enterprises.
Authentication problem
The third concern is that the dialogue mode of enterprise identity management may not meet the more complex requirements of SOA. In a simple transaction, the user is authenticated at the beginning of the session, and then this authentication will be applied to the whole session.
However, in the SOA model, the user may initially start a transaction and then disconnect from the server, and the transaction may pass through a set of back-end services, so the user has no direct contact with the final transaction. It is necessary to determine not only who initiated the transaction, but also who (or what in the automated process) approved and processed the transaction. It is necessary to authenticate the information used by all these individual processes in the transaction, instead of asking them for information in an interactive session. This is a problem that has not been completely solved until now, but SOA has increased the degree of this security vulnerability.
Because SOA is very powerful and can be used to easily utilize external programs and programs of other external trusted partners, this defect may become very large. Enterprises need to carefully formulate safety strategies, cultivate users' safety awareness, and assist with appropriate technologies to minimize the risks they face.
The best way to solve this problem is to use the security assertion markup language to create a representative identifier that can be attached to a transaction.
Security is a key point in SOA, because SOA emphasizes the interaction between machines, while most IT security is based on the interaction between people and machines. In this environment, authentication and authorization become more challenging.
In unprotected SOA, it is practically impossible to prevent unauthorized use of Web services; Unauthorized users can access Web services very easily. Web services do not track who is using them or who is allowed to use them. Unnecessary interception and message interception cannot be prevented.
Unprotected SOA gives hackers the opportunity to listen to SOAP messages and view private information. Moreover, in an unprotected SOA, it is relatively easy to listen to SOAP messages and resend them or transform their contents.
Because of the openness of SOA architecture, you can't protect unknown third parties in SOA. Secondary and tertiary users (such as your partner's partner) can access unprotected SOA. Therefore, unprotected SOA is easily overloaded.
Without access control, unprotected users will provide SAML assertions of trusted authentication.
Web service application proxy receives and processes SOAP requests in actual Web services, which contributes to security. Its SOA is easily "overwhelmed" by a large number of SOAP messages from hackers. Therefore, DoS attacks may destroy the normal function of the system.
When analyzing the security requirements of SOA, we can consider implementing an SOA security solution that supports SOAP message monitoring, federated authentication, application proxy, contract management, certificates, keys and encryption, and audit records. This list seems long, but in fact, all the advantages of SOA may be destroyed if any one of them is missing.
SOAP message monitoring uses SOAP interceptor model to monitor and intercept SOAP messages sent from calling system to Web service. SOAP message monitoring is the foundation of SOA security, because it enables security solutions to stop and analyze each message for user authentication and authorization.
To protect third parties, security solutions utilize federated authentication processes, thus providing the ability to authenticate users in the system. In the end, you will get a Web service that can keep all users away from the actual service. Proxy can not only reduce the network load, but also provide an additional security layer for SOA.
Contract management is another SOA management feature that contributes to security. The contract stipulates who has the right to use the Web service and when it can be used. Contract improves the security of SOA by eliminating the use of non-contractual parties.
Certificates, keys and encryption are also essential for a truly secure SOA. The most robust SOA security comes from the implementation of encrypted messaging using the private key/public key from the certification authority for authentication. XML encryption allows Web service users to send encrypted SOAP messages that retain XML format. Therefore, the system achieves security, but it is still based on standards. Digital signature is a variant of encryption model, which enables users of Web services to create a unique digital "signature", thereby verifying the identity of users and ensuring the integrity of message data.
Finally, in order to track the use of SOA, it is necessary to adopt an SOA security solution, which can save the dynamic audit log of all SOAP message requests and responses. Audit log is necessary to study security issues and diagnose security vulnerabilities in SOA, and to achieve compliance with management regulations.