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 reroute SIEM 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. 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----- MIIEowIBAAKCAQEA4jk8fUW/WGbKy/5pYw+OV8D1xOLoq4wiCNJBx9JwJFJSpxq9 3z1H1Kw7nLd15LnTfNBiS3oCT1eDracVBBIKCftoTzBMQrpdi6ZDOUQH6QFAo4KX Tv2ZBRJYPTQEqqWY0sLOUvtnmjZ00v5UP1kAIK5fIIOrzFCqIgoSaB2p2UW00ULh zb+4O2PIUf5ve9ev8pk88ktyFMdQ+/yvn1HMamuoQJO+gnFb3cxqGF+oxiQM58V0 xPZ9vxrmnjBKFWy/GIPWvZMIvW5Ex663iAeFEkj5uIg0se+n9v3/vuYfErP0dLC9 pT4leb5wHWCDVofn1gNB4o8pPsJ+UvxK2oHDDwIDAQABAoIBAQCPPqLYyANjXKNp DE17FmyRkHOPGgcuKOucHlbcypmLxjzj5wD3jHwhZHXSxDB4hlouHF1BYZ540vdk S/n4u9tzeqgQDIsdbZiyRrMmXbeMiOh/IL/imp38IiORjZCu5XChdAzlap+tfHH4 8GY0PozgJMnDctyj4Sf5qdsB5laYZmPNLhPKsIIe31KXEpSkpYV1LbQWc7Kjgdya cOXuApaCwpCfvXVyPmGOyubjYTK6eYb0s0JNofyQtkmqfupPCZmv16TMSpwJnlib ryY2xN+fHSMBhDnTxMZjWsqU9/jTZ9+7patZmwsLI2Ko9s1kFA4P26Gofc+h8AQQ Z7JmummRAoGBAP9aK9RKOLGREzAxyzS0wEEBMQSC/3wx4+OWz558r17tIC3MO sK9NC5++YhmugsI8JOEKilhaVnxVRFb5v8jwI8GBYeRS3rOQDBvCMWAst/okoq1BoI9 kv75HXY4FGryiRjvpuNJHe1COpdwsn2yxLAHgHDT/PUPH8r0KVEOpDfVAoGBAOLM JgmSwCh2dj2Zj634Mg7ZzCZlTec1gzP4+bB/uJiED82yW4reJn0tZSZgpdZr7fDn xPQa0T58iNT4ZzHpH3s9Cevm+x5sLGAdCGP4VVVsQkJCi8Gt+ffLGWQOys7XVQvW iMeS2sPrFC1JNu8a7QShIkmcNsdnauVpFzyUOoVTAoGAAKKVx1Jj77UfqhgFnFzy uXaqS4uT3Rg2q+M9IvTGbuMCGHsQjllwHsl8D2XKAqsEBinm/PFcFLgv8Pociffp y7FFJEAtQuHucPBlwi/+weXPL38hxAMpMW8nLpsXGej+hExcSuZsp6FpieTi3MMs EBAEtsMgNu/RsWyICcaSi/0CgYBdu94kqsA8eOlZgDP/xMp7lMxpOgk+e8FkI4ye w8q5Titx6jsnY7UomzBo8hzYR/cpT8D42nSMjM/IpXmRCTZ3qryFAQvcgPy+JIGp P6OVEI8572Lvg0YCgbBWyD5NynVd1SbmxO0hd/D43n+Txt8awLX5ElUZiMaHVi3C Xcjp/QKBgGvB/z3NcDUE7IHg1PL4erhT4A2gWC8fa+NfLwsWhCQIB3/9UHzlm3Gs I1r84OReI+XOsSysJGWyvkvThEdXl28BHMY3iCoHLPVfKxhNX73O3LXUSB/E3s2i GnmuqJi5/Sd22yVXjE4UCbDpOTJdJZxHsCVPUFCX/9tnVeYUsSrR -----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:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWKvQV0MoER+0mv+KGRDxY7b39yrEGo6qiQ0xPM8vhDp 5JMjm9k4KFSVrx0qewp2AsCl3qamJcvaStyxBZTfhIFsEWt1BAtixki0WRj8iTDugtXhdu65lGYuxkLiGWUNZu 5OTXSA/6usdtvUgS7WIeeFWWl0jYwoU4cLGbafldSDfH77Ab1m6PbZGaIw7rJLZkkY+yPan/0ONzIEfTJdBU ZI4g+MfFvTcsCG5Jo3AqGV/g08hL8/SFMhbtKFAIslAkmmcEP1Oj27AAj6EtoD8YqjJZtO6uDq7KApq2J/M499 NKhHGnrPI23AqgaOBNDdJNgj51zYKyhNudUI1ap+qt firstname.lastname@example.org
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:
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 operations to delete old keys and replace them with new keys. See the article Manage SIEM event public keys for more information.
Updated 9 days ago