Important. When you enable SIEM Event Delivery, Akamai assigns you an Amazon S3 bucket and provides you with the information needed to log on and retrieve data from that bucket. You can download files from the S3 bucket and you can delete files stored in the S3 bucket. However, you can't upload files to the bucket: that results in an Access Denied error. That's because, in the end, the bucket is owned and managed by Akamai. You have access to the S3 bucket, but that access is somewhat limited.
In addition, you must use this bucket for your SIEM data feeds: there's no way to rerouteSIEM event deliveries to a different S3 bucket or a different location. The SIEM event APIs are hard-coded to use the Akamai-owned S3 bucket as a data repository, and that can't be modified.
Access to the Amazon S3 bucket associated with a SIEM delivery feed is managed through the use of SSH keys: public keys are registered with the S3 bucket, and any user attempting to connect to that bucket must have a private key associated with one of those public keys in order to gain access. Note that organizations are responsible for creating and maintaining their SSH keys.
Although there are a number of ways to generate SSH keys, key pairs can easily be created by using the ssh-keygen application. For example, if you have ssh-keygen installed you can create a new key pair by running this command line command:
ssh-keygen -m PEM -t rsa
The preceding command creates a private key that is stored on your local computer (when you run ssh-keygen you’ll have the opportunity to specify a name and a location for the key). The private key (which is typically not shared with others) will look similar to this:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
As we noted, the private key must be stored on your computer and then referenced when you connect to the S3 bucket. For example, if you are making your SFTP connection by using Cyberduck and you named your private key s3_bucket, your Cyberduck SSH Private Key field should be configured like this:
When you run ssh-keygen you’ll also create a public key, identifiable by the .pub file extension tacked on the end of the file name (for example, the private key s3_bucket will have a corresponding public key named s3_bucket.pub). The public key, which must be added to the S3 bucket, will look similar to this:
When you attempt to connect to the S3 bucket, you’ll forward the value of your private key as part of your request. The S3 bucket will then check to see if it a public key associated with the private key has been assigned to the bucket. If it has, access is granted. If it hasn’t, access is denied.
Incidentally, you can easily retrieve the value of a public key simply by typing a single command from the command prompt; just make sure that you specify the path to the public key file. For example:
How Many Public Keys Can I Have?
Amazon currently limits each S3 bucket user to a maximum of 10 public keys. However, the SIEM Event Delivery service will only provision one user account for each application. That means that an application is limited to 10 public keys (because there’s only one user name).
Incidentally, your user account name will look something like this:
That’s the word user_ followed by the application ID (htb8fuhxnf8e38jrzub3c7pfrr).
However, you aren’t limited to using the same set of 10 keys forever and ever. If you prefer to periodically rotate your public keys, you can use the SIEM Event Delivery API endpoints to delete old keys and replace them with new keys. See the Managing Public Keys section of this documentation for more information.