Category: General

同僚の Sanjay Padhi は AWS サイエンティフィックコンピューティングチームの一員です。Sanjay は、重要な科学的発見に役立つコンピューティングリソースを AWS がどのように提供したかに関するゲスト投稿を行いました。 – Jeff 質量の起源への洞察を提供する上で重要な役割を担うヒッグス粒子 (神の粒子と呼ばれることもある) は、2012 年に、スイスのジュネーブにある CERN の大型ハドロン衝突型加速器 (LHC) で、世界最大の実験装置である ATLAS および CMS により発見されました。この発見の基盤となる理論を提唱した研究者たちは、2013 年ノーベル物理学賞を受賞しています。 フランスとスイスの国境にまたがって地下深くに設置されている LHC は、世界最大 (全周 17 マイル) でこれまでにない高エネルギーの粒子加速器です。これにより、これまで探求してきたいかなる人間の発明よりも小さいスケールで自然界を探ることができます。 実験から生データへ 高エネルギー粒子の衝突により、質量はエネルギーに変換され、その後質量に再変換されて、新しい粒子が作り出されます。この粒子が CMS 検出器で観察されます。この検出器は長さ 69 フィート、幅 49 フィート、高さ 49 フィートで、フランスのセシー村近くにある地下 328 フィートのトンネルに設置されています。CMS からの生データは 1 秒あたり約 1 ペタバイトの割合で 25 ナノ秒毎に記録されます。 CERN Tier 0 データセンターで生データをオンラインおよびオフライン処理した後、そのデータセットは 48 […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 28 日 AWS Security Blog が、AWS CloudTrail を使用してフェデレーションユーザーを簡単に識別する方法を掲載しました。 BotMetric が、AWS セキュリティベストプラクティスの投稿シリーズに、データセキュリティと検出サービスについての 2 つの投稿を新たに追加掲載しました。 Evident が、AWS 用のプログラムによるセキュリティの自動化についての記事を掲載しました。 Cloud Academy が、AWS DevOps Pro 試験に合格するのに役立つヒントを掲載しました。 Cloudonaut が オブジェクトストアとしての Amazon S3 の活用法を掲載しました。 Gorillastack が、より多くのコンピューティングリソースを Amazon EC2 スポットインスタンスに移行する必要がある理由を掲載しました。 The Register が、Amazon WorkSpaces のリリース後のこの 2 年間を振り返る記事を掲載しました。 火曜日 3 月 29 日 AWS CloudFormation で変更セットが利用できるようになったことを発表しました。 Amazon […]

こんにちは。プロダクトマーケティングマネージャーの石橋です。 2016年は、Amazon Web Services（以下、AWS）が2006年に事業を開始してから10年、2011年に東京リージョンを開設して5年と、節目の年を迎えました。当時はクラウドのパイオニア、今ではある意味老舗になってきたAWSです。特に、ここ数年で多くの企業においてクラウドの活用が進んでいることをニュース等で目にするようになりました。同時に、AWSも多くのお客様にご利用いただけるようになりました。なぜ、AWSは成長し続けているのでしょうか？理由を考えてみたいと思います。   ■10年前のクラウド、今のクラウド クラウドと言えば、システム構築のためのITリソースであるサーバやストレージ機器を、自社や個人で購入、所有することなくインターネット経由で提供し、必要な時に使った分だけ支払う従量課金や、ものの数分でITリソースを準備できる俊敏性が利点のビジネスモデルとして注目されました。AWS設立当時は、いかに早くビジネスを立ち上げ、その結果から次の打ち手を考えることができるかという利点が活かせる、スタートアップ企業を中心にご利用いただいていました。ここ数年は、以前とどう変化したのでしょうか？導入するお客様の業種や事業内容、企業規模は多岐に渡り、お客様の求めるサービスやセキュリティレベル、堅牢性や可用性のニーズに合わせたサービスを提供できるようになりました。AWSクラウドのセキュリティコンプライアンスへの準拠（第三者認証や監査）、専用線によるAWSクラウドへの接続、無料かつ自動更新のSSL証明書（US East（Northern Virginia）リージョンのみで提供）※など、企業においてクラウドにおけるガバナンスが効くようになり、利用している企業だけでなく、さらにその先のお客様が安心してサービスを利用できるようになりました。また、お客様と共にサービスを拡充し続けることで、多種多様な企業においてご利用いただけるようになりました。   ■クラウドによるビジネスモデル変革 導入が進むクラウドですが、AWSが最初に起こしたビジネスモデルの変革は何でしょうか？それは「ITリソースの購買体験を大きく変えたこと」です。必要な時に使った分だけ、事前の契約なしに、誰でも購入できる体験です。従来のITリソースの購買（調達）体験をシステム導入のライフサイクルから考えてみましょう。システム開発のライフサイクルには、ビジネス要件の定義、インフラ設計、システム設計（サーバサイジング設計や容量計画）、ソフトウェア設計、ソフトウェア開発、運用管理設計、システムテスト、システム運用（メンテナンス）、End of Service(EOS)と一連の流れがあります。この中で、AWSのクラウドで費用・人的労力・時間を軽減したり短くする（＝どこか別のところに任せる、考える時間を少なくする）ことができる部分はどこでしょうか？すべての開発サイクルでクラウドにワークロードを移行できます。   ■クラウドがビジネスにもたらす利点 ワークロードを移行した結果、ビジネス上の利点は何でしょうか？今までオンプレミス環境を構築している場合、ITシステム構築のワークロードは自社内にありました。これらのITワークロードをクラウド側で処理できるとすれば、システムの導入初期費用だけでなく、中長期にわたり運用する為の人的工数、ハードウェア・ソフトウェアのライセンスやメンテナンス費用まで含めたTCO削減につながります。そして重要なのは、ITワークロードをオフセットしたことによる調達や作業「時間」を、今まで手が付けられなかったことや新たな事業に投資することで、さらなる事業展開の可能性を創出できるようになることです。仕事の仕方が変わるという事なのです。   ■AWSが成長し続ける3つの理由 AWSはテクノロジーの変化に合わせて、お客様のビジネス形態も変化していることをいち早く捉え、ビジネスのパートナーとして共に成長しています。AWSの成長はお客様の変革によってもたらされています。それでは、AWSが成長し続ける理由を見てみましょう。   (1) お客様が事業に集中できる 企業や組織内の事業基盤にある技術インフラをAWSにすることで、お客様を差別化するための事業に集中できる状況を作っています。そして長期間に渡って競争力を維持し続ける為の支援を、AWSおよびパートナーエコシステムを活用し一緒にビジネスを行っています。   (2) イノベーションを起こすためのインフラ提供 すべての企業は生き残るためにビジネスや顧客体験を変えていく必要があります。コストの低減は守りの一要素ですが、その先にはビジネスの俊敏性や変革が必要です。そのためのインフラも俊敏、柔軟で革新的であるものを提供し続けています。   (3) ITに必要なモノをあらかじめそろえておく 企業内で使うITリソースは多岐にわたります。必要なモノはできるだけAWSで準備し組み合わせて使うことで、ビジネスのニーズに合わせたアウトプットを、より早く、より簡単に提供できるようになります。2015年は722ものサービスリリースや機能改善を行いました。お客様に、その継続的な進化や革新による利点をすぐに享受していただけます。     クラウドサービスの検討をはじめた方は、どこから手を付けていいかわからない方もいらっしゃると思います。弊社のホームページでセミナー情報を探していただくと、「はじめてのアマゾン ウェブ サービス」や「初級トレーニング」といった無料でAWSを知る機会がありますので、是非活用してみてくださいね。すぐにでも始めてみたい方は、AWS にサインアップした日から 12カ月間お使いいただける無料利用枠があります。ほとんどの製品をお試しいただけます。ユーザ登録は簡単ですので試してみてください。   AWSアカウントの作成手順はこちら http://aws.amazon.com/jp/register-flow/   ※サービスを提供しているリージョンは3/25現在の情報に基づいています。    

Airbnb は、わずか数人のすばらしい着想が業界全体を大きく変えることがあることを示す、典型的なストーリーです。2008 年にスタートして以来、これまでに 8000 万人の客が Airbnb を利用して 190 以上の国にある 200 万軒以上の家に宿泊しました。最近では、全世界からの旅行者のため、キューバに 4000 軒の家をオープンしました。同社はまた、早くから AWS を活用してきました。 ゲストによる以下の投稿の中では、Airbnb エンジニアリングマネージャーである Kevin Rice 氏が、スタートアップにおいて AWS がどれほど重要な役割を担ったか、そしてどのようにその重要な位置にとどまっているかを解説しています。 – Jeff PS – スタートアップが AWS を利用してビジネスを展開する方法の詳細についてもご覧ください。 初期 当社の創設者たちは、Airbnb を成功させるために、スピーディーかつリーンであることが必要だと認識していました。これには、インフラストラクチャに投じる時間とリソースを最小化することが不可欠です。当社のチームは、ベーシックなホスティングについての業務にではなく、ビジネスを離陸させることに集中することが必要でした。 幸いなことに、ちょうどそのとき、アマゾン ウェブ サービスにはコンピューティングとストレージにおいて非常に成熟したサービスが構築されていたため、当社のスタッフは他の人からのサポートや最小使用要件に気を使うことなく、サーバーを立ち上げることができました。同社のクラウドコンピューティング機能のほぼすべてを AWS に移行することが決定されました。スタート当初の小さな企業では、利用できるリソースを可能な限り活用する必要があります。当社の従業員たちは、ビジネスを成功させるために替えのきかないところに注意を集中したいと考えていました。 Airbnb では、Amazon EC2 や Amazon S3 といった AWS の基本サービスの多くをすばやく導入しました。当初の MySQL データベースは Amazon Relational Database Service (Amazon RDS) に移行されました。RDS […]

本日、AWSの暗号化チームは AWS Encryption SDKを発表します。この新しいSDKによって、開発者は、アプリケーションのセキュリティに影響を及ぼしうるエラーを最小化しながら容易に暗号化を実施できます。新しいSDKはAWSのお客様でなくてもご利用いただけますが、AWSのお客様にとってすぐに利用可能なサンプルが含まれています。   暗号化を行う際、開発者は次の2つの問題によく直面します: どのように正しく暗号鍵を生成し、利用するか 利用後、鍵をどのように保護するか 新しいAWS Encryption SDKによって提供されるライブラリは、ユーザーの開発環境で利用可能な暗号化プロバイダを利用し、低レベルの詳細な部分を透過的に実装することで1つ目の問題に対応します。また、どのように鍵を保護したいかを選択できる直感的なインターフェースを提供することで2つ目の問題への対応を手助けします。開発者は、暗号化の複雑性ではなく構築しようとしているアプリケーションコアにフォーカスすることが出来ます。この記事では、AWS Encryption SDKを利用してどのようにデータの暗号化プロセスを簡素化できるか、単一のリージョンあるいは鍵管理ソリューションに縛られない、アプリケーションの可用性を改善するのに役立つ方法でどのように鍵を保護できるかについてお伝えします。   エンベロープ暗号化と新しいSDK AWS Encryption SDKを利用する際に理解しておくべき重要なコンセプトは、エンベロープ暗号化(ハイブリッド暗号化としても知られています)です。アルゴリズムが違えば強度も異なり、単一のアルゴリズムで全てのユースケースにフィットするものは有りません。例えば、(RSAやAWS Key Mangement Service [KMS]などの)優れた鍵管理の特性を持つソリューションは、大容量のデータに対してはあまり有効ではありません。エンベロープ暗号化は、(AES-GCMのように)大容量データに適した単一用途のデータキーを使ってバルクデータを暗号化することでこの問題を解決します。エンベロープ暗号化ではその後、鍵管理に適したアルゴリズムや他のソリューションを使ってデータキーを暗号化します。 エンベロープ暗号化のもう一つの優位性は、複数の受信者で復号化できるようひとつのメッセージを暗号化できることです。全員で鍵を共有(これはたいていセキュアではありません)したり、全体のメッセージを複数回暗号化したり(これは現実的ではありません)するのではなく、データキーだけがそれぞれの受信者の鍵を使って暗号化されます。これによって重複した処理を顕著に削減でき、複数の鍵を利用した暗号化がより実用的になります。   エンベロープ暗号化の問題点は実装の複雑さです。全てのクライアントはデータフォーマットの生成および構文解析ができ、複数の鍵とアルゴリズムをハンドルでき、理想的には妥当な範囲で前方および後方互換性を保てる事が必須になります。   AWS Encryption SDKはどう役立つのか？ AWS Encryption SDKは、セキュアなアルゴリズムの組み合わせ(将来的に拡張可能)をサポートし、マスターキーのタイプやアルゴリズムの制限が無い、慎重にデザインされレビューされたデータフォーマットを採用しています。AWS Encryption SDK自身は、KMS、および AWS CloudHSMやその他の PKCS #11デバイスを含むJava Cryptography Architecture (JCA/JCE)を直接サポートするpoduction-readyなリファレンスJava実装です。他言語でのSDKの実装については現在開発中です。 AWS Encryption SDKの一つの利点は、低レベルの暗号処理はSDKで取り扱われるため、データの移動にフォーカスすることができることです。次に、パワフルでセキュアなマルチリージョンソリューションを構築する簡単なコードを示します。   Example 1:高可用性のためにアプリケーションの機密データを複数リージョンのKMSマスターキーで暗号化する 高可用性アプリケーションのベストプラクティスの一つは、複数のアベイラビリティゾーンだけではなく複数のリージョンでデプロイすることです。KMSはリージョンをまたがってカスタマーマスターキー(CMK)を共有できないため、データがKMSで暗号化されている場合にはこのようなデプロイメントは困難です。エンベロープ暗号化では、異なるリージョンの複数のKMS CMKを使ってデータキーを暗号化することでこの制限に対するワークアラウンドを取ることができます。各リージョンで稼働するアプリケーションは暗号文の復号化を行うために、高速で信頼性の高いアクセスのためにローカルのKMSエンドポイントを利用することができます。 このドキュメントの全ての例において、 IAM roles for EC2を設定したAmazon EC2インスタンスが稼働していることを想定しています。IAM […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 21 日 スポットフリート用の新しい CloudWatch メトリックスを発表しました。 AWS SDK for Java 用の再試行スロットリングを発表しました。 AWS マネジメントコンソールを介して Amazon Machine Learning を Amazon Redshift に接続することが簡単になったことを発表しました。 AWS Storage Gateway で最大 1 PB の仮想テープライブラリと、ゲートウェイあたり最大 512 TB の保管型ボリュームをサポートするようになったことを発表しました。 AWS Government, Education, & Nonprofits Blog が、AWS にすべてを移行した際に学んだ教訓についての記事を掲載しました。 AWS Mobile Development Blog が、CloudFormation を使用して AWS に Parse Server と MongoDB […]

週間 AWS – 2016 年 3 月 14 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 14 日 AWS SDK for C++ の開発者プレビューが使用可能になったことを発表しました。 AWS クラウド 10 周年を祝いました。 Sqoop、HCatalog、Java 8 などを含む Amazon EMR 4.4.0 をスタートしました。 AWS コンピューティングブログで、欧州 (フランクフルト) リージョンにおける AWS Lambda および Amazon API Gateway の使用開始を発表しました。 Amazon Simple Email Service ブログで、Amazon SES がドメインからのカスタムメールをサポートするようになったことを発表しました。 AWS Java ブログに、Amazon SQS […]

AWS IoT のルールでデバイスが生成したデータを直接、 Amazon Elasticsearch ドメインに渡すことができるようになりました。これによってデータを分析したり、データに対してフルテキストやパラメータによる検索を実行したり、 Kibana で可視化したりすることができます。この連携によって、デバイスの特定のエラーコードをフルテキスト検索したり、デバイスのパフォーマンスをリアルタイムに近い形で視覚化するような、ユースケースをサポートします。 加えて、AWS IoT のルールによって、デバイスが生成したデータを Amazon CloudWatch に発行することができるようになりました。これによって、デバイスのメトリックスをグラフ化して見たり、アラートをセットすることができます。 これらの新しいルールをどのように利用するかについての、より詳しい情報については、AWS IoT デベロッパー ドキュメントを参照してください。または、コンソールにサインインして、ルールを試すことができます。   日本語への翻訳は SA福井が担当しました。原文はこちらです： https://aws.amazon.com/jp/about-aws/whats-new/2016/03/aws-iot-integrates-with-elasticsearch-service-and-cloudwatch/  

週間 AWS – 2016 年 3 月 7 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 7 日 AWS CodeCommit 向けの通知をスタートしました。 新規の AWS アカウントがデフォルトで長い EC2 リソース ID に設定されるようになったことを発表しました。 AWS セキュリティブログに、AWS IAM および AWS CloudFormation を使用して VPC へのアクセス制限を自動化する方法を掲載しました。 Botmetric に、AWS セキュリティの脅威に対する取り組みの現状: アクセスコントロールが掲載されました。 CloudCheckr で、AWS の多様なサービスを有効に活用するための 5 つのヒントが共有されました。 CloudEndure に、2016 年に必読のクラウドコンピューティング書籍トップ 5 が掲載されました。 Cloud Academy から、AWS CloudWatch によるログ管理の一元化シリーズのパート […]

  Amazon.comのCTO  Werner Vogelsが、彼のブログでこの10年のAWSの軌跡を振り返っています。ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。 ——————– AWSの革新は2006年3月14日のAmazon S3のローンチで、約10年前の出来事でした。10年前を振り返ると、低価格で予測可能なパフォーマンスにより、セキュアで、信頼性があり、拡張性が高い、構築・運用が実現できていることから、数百もの学びがあります。AWSは、世界規模でサービスを構築・運用できるパイオニアであり、これらの学びは我々のビジネスにとってとても重要です。以前も何度となくお伝えしている通り、経験だけはショートカットするする方法がない、ということです。毎月の数百万ものアクティブなお客様と共に、彼らの先にいる数億ものお客様と共に、お客様にサービスを提供しながら改善するためのまたとない環境と学ぶ機会を得ています。 みなさんと共有したいいくつかの学びをご紹介します。 1. 進化可能な仕組みを構築する ビジネスが始まる初日から、開発していたソフトウェアは、もはやソフトウェアに非ず、ということを一年間走らせてみてわかりました。その期待値は、金額でいえば一桁、二桁も異なり、スケールの問題を解決する為のアーキテクチャの再考が必要になったものです。   とはいえ、世界中で24時間365日多くのシステムが我々のプラットホームで動作しているのですが、システムアップグレード時にメンテナンスによる中断を起こさないようにする形態をとることはできませんでした。我々は、サービス停止を起こさずに新たなコンポーネントを導入できるアーキテクチャを作る必要がありました。Marvin Theimer, Amazon Distinguished Engineerの彼が、Amazon S3を例えば言うならば、当初は単機エンジンだったセスナが、時間を経過するとボーイング737や747sにアップグレードされている、そして最後はエアバス380sのようだ、と冗談まがいに言っていました。成長の途中で、空中燃料補給をしながら、お客様に築かれないように飛行機を乗り換えているようだと。   2. 想定していないことを想定する 失敗はもたらされるもので、すべてが最後は失敗に成り立っている。ルーターからハードディスク、OSからメモリユニット、誤ったTCPパケット、一時的なエラーから、永続的な故障などがあります。これは、最高品質のハードウェアであろうが量産品であろうが、最終的な顛末は同じです。 拡張性において、さらに重要になってきます。例えば、S3が数兆回ものトランザクションを処理しているときでも、ほんのわずかな可能性でも、それは現実に起こります。このような故障のシナリオの多くは事前に予知できますが、設計や構築時点では知る由もありません。 我々は、故障が何なのかは知らずとも、自然発生で起こる故障も冗長化しカバーできる構築が必要でした。システムがもし火事にあったとしても動作し続ける構造が必要なのです。システム全体をダウンさせることなく、個々のモジュールを管理できることが重要です。我々は、システム全体のヘルスチェックを可能にするような、故障発生時の影響範囲を管理する基本的な仕組みを開発しました。   3. フレームワークでなくプリミティブ ほどなくして、AWSのサービスを利用したいと考えている企業の多くは既に何らかのAWSサービスを取り組んでいると気づきました。お客様が制約を許容し、過去のIT関連のハードウェアとデータセンターの世界と決別すると、前例のない使用パターンで構築し始めるということが起こりました。そのように、お客様のニーズに合ったものを確実に届ける為に、素早く動かざるを得ない状況でした。 もっとも重要な事のひとつに、小さなサービスやツールをお客様に届けるという事で、ひとつのフレームワークを強制されるよりも、キッチンの道具のようにすべてそろっていて組み合わせるように、AWSクラウドで実現できる最適な方法を選んでいただけるような構成にしていました。この方法はお客様の成功につながりましたし、後にAWSのサービスの基本的な製品／サービスの考え方をして活用しています。 お客様がサービスを手に取り、使って構築するまで、どのような優先順位で対応すべきか予期することは難しい、ということに気付くのが重要です。最小の機能性でサービスをリリースし、お客様の要望に合わせてサービスのロードマップを作っています。 4. 自動化がカギ サービスを構築するのと従来のソフトウェア開発でお客様に納品するのとは大きく異なります。拡張性の高いシステムを管理するには、お客様の期待する信頼性、パフォーマンス、スケーラビリティに合うようにする異なるマインドセットが必要です。できるだけ自動化を可能にし、マニュアル操作とエラーを事前に取り除く管理方法を実現するには自動化が重要なカギになります。実現するには、操作に重要となる機能を制御するAPIを構築する必要がありました。お客様にも同様に助けになることです。アプリケーションの構造を分解し、それぞれ管理用APIで、拡張可能でパフォーマンスとメンテナンス性に優れたルールを作ることができます。 5. APIは永続 アマゾンの小売りの経験から得たものでもありますが、AWSがAPI中心のビジネスになることはさらに重要です。お客様が我々のAPIを使ったシステムとアプリを構築し始めたのなら、お客様のビジネスに影響を与えるとして、APIを変更することは不可能になります。APIのデザインは非常に重要であり、正しく設計できるチャンスは一度きりだということを肝に銘じねばなりません。 6. リソースの使い方を知る 適切なサービス利用料を特定しサービスを見積もる際には、コストと運用の良いデータを手に入れることです。特に薄利多売のビジネスモデルにおいてです。AWSはコストを低減させるための努力を惜しまないため、お客様に届けるサービスも投資してもよいと思えるものであり、さらに値下げしても運用継続可能な範囲を見極め、利益を低価格という形でお客様に還元しています。 先の一例として、S3ではどの程度使用されるかパターンがわかりませんでした。ですから、ストレージとネットワークの帯域に対して主な課金を行うというように仮定しました。しばらく運用した後、リクエスト回数も同様に重要な指標だと気づきました。もしお客様がたくさんの小さなファイルを持っているとすると、ストレージと帯域は何百万件のリクエストであろうと計算しませんでした。我々は、AWSのビジネスが継続的なものになるよう、計算モデルを調整しなければなりませんでした。 7. ゼロからのセキュリティ対策 お客様をセキュリティの脅威から守ることは、運用の観点においても、提供するツールや仕組みにおいても、AWSとしては最優先すべき事項です。我々が永遠に投資をし続ける領域です。 素早く学ぶひとつのアプローチとして、最初にサービスを企画・設計する段階で、セキュリティ対策を組み込んでおくことが必須です。セキュリティの専門チームは、何かを構築してから検証するチームではありません。サービスが始まるその日からパートナーとして基本的なセキュリティが担保され強固であるか確認しています。セキュリティに関しては妥協しません。 8. 暗号化は最良の住人 暗号化はお客様にとってデータにアクセスする人に対する最大の制御方法であると言えます。10年前、暗号化のツールやサービスは使いにくく、我々のサービスにどう組み込むのがベストか検討しました。 暗号化はコンプライアンス順守の観点で、サーバーサイドの暗号化をS3で実装しました。もしあなたがデータセンターでディスクをのぞき見しようとしても、どのデータへもアクセスはできないでしょう。しかし、Amazon CloudHSMと後のAmazon Key Management Serviceを使えば、お客様は独自キーの管理とそれを使った暗号化ができるようになります。 今では、暗号化対応は新サービスには企画・設計段階で統合されています。例えば、Amazon Redshiftは、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。 暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。 […]