カテゴリー: tech

  • オンプレ⇄AWS Storage Gateway 間のセキュアな接続について

    AWS Storage Gateway はCHAPを使用して、ゲートウェイと iSCSI イニシエータの間の認証を行うことができる。

    CHAP を設定するには、AWS Storage Gateway コンソールと、ターゲットへの接続に使用される iSCSI イニシエータソフトウェアの両方で、設定を行う必要がある。

    Storage Gateway では相互 CHAP が使用され、イニシエータがターゲットを認証するときに、ターゲットもイニシエータを認証する。

    セキュアな iSCSI接続を実施するために必要なこと

    • CHAP(Challenge Handshake Authentication Protocol)を構成する
    • その上で、iSCSIとイニシエーター接続を認証する

    iSCSI イニシエーターとは

    iSCSI によって接続された機器に対する指示を出す部分

    参考情報

    https://wa3.i-3-i.info/word12375.html

  • VMware のインスタンスを AWS に移行する

    ダウンタイムを許容する際の移行方法について

    AWS Server Migration Service を使った移行

    AWS Server Migration Serviceを利用して、物理マシンのみならずVMware vSphereインフラストラクチャからAmazon EC2に仮想マシンをインポートすることができる。

    https://aws.amazon.com/jp/server-migration-service/

    AWS Server Migration Service は、短時間で AWS に移行できるサービス。

    ライブサーバーボリュームの増分レプリケーションの自動化、スケジュール設定が可能。

    VMware のインスタンスに対してAWS SMSを利用する際は、AWS Connector for vCenterと言うコネクターを移行対象となるオンプレミス環境のサーバーにインストールする。

    これにより、GUIを使用してVMware vSphereインフラストラクチャからAmazon EC2に仮想マシンをインポートできる。

    1. VMware vCenter から Amazon EC2 に移行する仮想マシンから EC2 インスタンスを起動。
    2. AWS Connector for vCenter を使用して仮想マシンを Amazon EC2 に移行

    と言う順番で行う。

    VM Import/Export を使った移行

    VM を既存の仮想化環境から Amazon EC2 にインポート、それを元の環境にエクスポートすることができる。

    この方法を使うメリットとして、

    • アプリケーションを Amazon EC2 へ移行
    • VM イメージカタログを Amazon EC2 にコピー
    • バックアップと災害対策のために VM イメージのリポジトリを作成できる

    といった点を挙げることができる。

    VM Import ではインポートプロセス中に VM が Amazon EC2 AMI に変換される。

    https://aws.amazon.com/jp/ec2/vm-import/

  • クロスアカウントアクセス

    やりたいこと

    以下の振る舞いを持つ サードパーティの Webアプリケーションを使用する際の制御

    • 自社のAWSアカウント内で実行されている EC2インスタンスへの API コマンドを発行するアクセス権が必要
    • 第三者による目的外利用ができない形式で権限を付与させる

    外部から自社の エンドポイントを叩くユースケースへの対応を考える必要がある。

    クロスアカウントアクセスで考えるポイント

    クロスアカウント許可を設定するIAMロールによって、限定的なアクセスを委任することができる。

    WEBアプリケーションが必要とする権限のみに限定したアクセス権限を付与したIAMポリシーを設定する必要がある。

    それに基づいたクロスアカウントアクセスが可能となるIAMロール(サードパーティ社用のロール)を作成し、該当WEBアプリケーションに設定する流れだ。

    これにより、第三者に資格情報を漏洩することなく、IAMロールの管理によって第三者の情報もコントロールすることができるようになる。

    ユーザーが所有する異なる AWS アカウント にあるリソースへのアクセスを委任する方法としてクロスアカウントアクセス許可とIAMロールの設定がある。

    特定のアカウントにある特定のリソースを別のアカウントのユーザーと共有することができる。

    クロスアカウントアクセスを設定するメリットとして、利用者はアカウントごとに IAM ユーザーを作成する必要がなくなる。

    参考情報

    ちなみに、API Gatewayを使う際、APIリクエストはIAMロールなどの権限がない外部システムやユーザーから実行が可能。

    また、AWS Organizationsはアカウントで IAM ロールを使って、特定のAWSアカウントのリソースへのアクセス権を別の AWS アカウントに付与できる。

    この場合は IAMユーザーを利用するわけではない。

  • Dockerfile での COPY コマンドによる「cannot copy to non-directory」というエラーについて

    Dockerfile での COPY コマンドによる「cannot copy to non-directory」というエラーについて

    Dockerfile

    COPY data /direcotry/

    上記 の通り記載したところ

    cannot copy to non-directory: /var/lib/docker/overlay2/mmfii39iwldt2x2p997ukyz4m/merged/directory/export

    というエラーになった。

    コピー先のディレクトリ名まで記載することで問題は解消できる

    COPY data /direcotry/data

     

  • 年月を、シェルでゼロ埋めする

    MONTH や DAY が 8 (一桁) の時、

    YYYYMMDD 形式でフォーマットが崩れないようにするためのワンライナー

    YYYYMMDD=${YEAR}$(printf "%02d" ${MONTH})$(printf "%02d" ${DAY})

  • VPC とサブネットで IPv6 の使用を有効にするためのステップ

    以下の順番に対応する

    1. AWS が提供する IPv6 CIDR ブロックを VPC およびサブネットと関連付ける。
    2. IPv6 トラフィックがルーティングされるようにルートテーブルを更新。

      パブリックサブネットの場合
      サブネットからインターネットゲートウェイに IPv6 トラフィックをすべてルーティングするルートを作成する。

      プライベートサブネットの場合
      サブネットから Egress-only インターネットゲートウェイに
      インターネット経由の IPv6 トラフィックをすべてルーティングするルートを作成する。
    3. IPv6 アドレスのルールを含めて、セキュリティグループルールを更新する。
      これを行うことでIPv6 トラフィックはインスタンスに出入りできるようになる。

      カスタムネットワーク ACL ルールを作成して、サブネットに出入りするトラフィックの流れを制御している場合、
      IPv6 トラフィックのルールを含める必要がある。
    4. インスタンスタイプが IPv6 をサポートしていない場合は、インスタンスタイプを変更する。
    5. サブネットの IPv6 アドレスの範囲からインスタンスに IPv6 アドレスを割り当てる。
    6. DHCPv6 を使用するように設定されていない AMI からインスタンスが起動された場合、
      インスタンスに割り当てられている IPv6 アドレスが認識されるように
      手動でインスタンスを設定する必要がある。 

  • オンプレミスのライセンスごとAWSに移行方法

    オンプレミスの DB2、SAP、Windows などを AWS に移行する方法について

    • 移行方法
    • ライセンスの管理方法

    上記2点を考える必要がある。

    移行方法について

    これらのライセンスをそのまま移行するためには、

    EC2インスタンスにソフトウェアをインストールすることになる。

    そのための移行方法としてAWS SMSを利用してECインスタンスへの移行が選択肢になる。

    ライセンスの管理について

    AWS License Manager を利用する

    AWS License Manager の特徴

    ライセンスルールを定義。

    ライセンス対象となるソフトウェアをインストールしたEC2インスタンスに適用することができる。

    コンソールを利用してライセンス利用状況を追跡することも可能。

    ソフトウェアベンダーのライセンスを簡単に管理できるようになる。

    管理者はライセンス契約の規約をエミュレートするカスタマイズされたライセンスルールを作成することで、EC2 のインスタンスの起動時にそれらのルールを適用できる。

    管理者はこれらのルールを使用して、契約が定める以上のライセンスを使用する。

    または短期的に異なるサーバーにライセンスを再度割り当てるといったライセンス違反を規制できる。

    AWS License Manager は AWS のサービスと統合し、1 つの AWS アカウントを通じて、複数のアカウント、IT カタログ、オンプレミスにわたってライセンスの管理を簡素化することができる。

    また、ライセンス管理者は AWS Service Catalog でルールを追加することができる。

    参考情報

    AWS Licence Manager

    https://aws.amazon.com/jp/license-manager/features/

    AWS Service Catalog

    https://aws.amazon.com/jp/servicecatalog/features/

  • Amazon Rekognition について

    Amazon Rekognition

    画像検品作業は可能だが、

    画像検品に特化したサービスではない

    もし画像検品などを行いたい場合は、

    G2インスタンスにソフトウェアを導入するなどの対応が必要。

    低レイテンシネットワーキングを備えた高度なグラフィック処理サーバーについて言及する場合は、EC2インスタンスの中のG2インスタンスが最適。

  • Amazon SWF について

    Amazon SWF の特徴

    • マネージド型の状態トラッカー
    • タスクコーディネーター

    ユースケース

    開発者が

    • 並行したステップ
    • 連続したステップがあるバックグラウンドジョブを構築、実行

    するケース。

    SWFはAWSサービスとの人間のやり取りを含むワークフローをサポートするが、

    現在ではワークフロー作成にはSWFではなくAWS Step Functions の利用が推奨されている

    AWS Step Functions よりも Amazon SWFの使用が求められるユースケース

    • 結果を親に返す子プロセスを起動する場合
    • プロセスにおいて介入する外部信号が必要な場合

    公式は以下の通り

    https://aws.amazon.com/jp/step-functions/faqs/

  • AWS Organizations の[組織の証跡]について整理する

    「組織の証跡」とは

    組織内のマスターアカウントとすべてのメンバーアカウントの CloudTrail イベントを同じ

    • Amazon S3 バケット
    • CloudWatch Logs
    • CloudWatch イベント

    に配信できるようにする設定である。

    組織の証跡を作成すると、組織のための統一されたイベントログ記録戦略を定義するのに役立つ。

    組織の証跡を作成すると、自分の組織に属するすべての AWS アカウントに、指定した名前の証跡が作成される。

    メンバーアカウントで CloudTrail アクセス許可を持つユーザーは、

    • AWS アカウントから AWSCloudTrail コンソールにログインしたとき
    • describe-trails などの AWS CLI コマンドを実行したとき

    この証跡 (証跡 ARN を含む) を表示することができる。

    各AWSアカウントでアクティビティが発生すると、そのアクティビティはCloudTrailイベントに記録される。

    イベント履歴に移動すると、CloudTrailコンソールで最近のイベントを簡単に表示できる。

    マルチリージョンおよびグローバルイベントの追跡を有効にすることもできる。

    デフォルトでは、CloudTrailによってバケットに配信されるログファイルは、

    Amazon S3管理の暗号化キー(SSE-S3)を使用したAmazonサーバー側の暗号化によって暗号化される。

    直接管理可能なセキュリティレイヤーを提供するために、

    CloudTrailログファイルにAWS KMS管理キー(SSE-KMS)を使用したサーバーサイド暗号化を使用できる。

    ログを保護するには、S3バケットを暗号化し、バケット作成時にデータ削除不可の設定を行うことで、永続的にログを保存することが可能。

    マスターアカウントに対して単一のCloudTrailを有効化して、ターゲットアカウント設定において他の子アカウントをターゲット設定・・・と言うことは必要ない。

    AWS Organizationsを利用して、CloudTrailの「組織の証跡」を利用することで子アカウントにも自動的にCloudTrailログを設定することが可能になるからだ。